Leaderboard

Marc, it sounds like you've got a bottleneck somewhere. You mentioned a remote DB connection, and maybe there's something to to that. You also mentioned Windows (I'm in unix), and it's certainly possible there's something platform specific going on. Here are some things you can do to narrow in on where it might be. Edit your /index.php file and before the line that says this: $config = ProcessWire::buildConfig($rootPath); Add this: Debug::timer('pwboot'); Now edit your /site/templates/_init.php file (or whatever gets called first) and add this at the top, after the "namespace ProcessWire;" (old school and rough, but gets straight to the point): die('Boot time: ' . (Debug::timer('pwboot')*1000) . ' ms'); Now you can get a sense of how long it takes ProcessWire to boot, before it hands off the request to you. This should give you an indicator as to whether you need to look at the modules you've got installed, or whether you need to look at the API calls in your templates. Hit reload several times in your site (front-end) to get a sense of the average boot time. On my oldish Macbook Pro and PHP 7, running the site-default profile with no 3rd party modules installed, these are my average boot times: ProcessWire 3.0.52: 53 ms (opcache off) ProcessWire 2.7.3: 104 ms (opcache off) ProcessWire 3.0.52: 35 ms (opcache on) ProcessWire 2.7.3: 35 ms (opcache on) As you can see, without PHP caching the code, ProcessWire 3.x boots nearly twice as fast as ProcessWire 2.7 (at least in my environment). Interestingly, if PHP's cache is enabled, then the boot time is identical. But when Soma said above “ProcessWire is getting slower and slower each iteration”, this is a blanket statement that is the opposite of reality. ProcessWire is getting faster and more optimized with each version. What's real is that clearly something about the conditions present in his environment and your environment is reducing performance, and that needs to be narrowed in upon. So the next steps will be to determine if it's something about the server, something from a module, or something going on in the template file(s), like some specific API call that might be common among your installations. Now go to your Chrome dev tools, Network tab. Hit reload several times like you did before (same URL). Note the first request in your Network tab. Take this time and subtract the time you recorded above. This represents (roughly) the time required to load PHP before it gets to ProcessWire. With opcache off, my PHP takes about 100ms before it loads ProcessWire's /index.php file. If I enable opcache, then I'm seeing almost no overhead from PHP at all. Meaning, Chrome dev tools is showing 40ms or less. I'm guessing that your remote DB connection is going to mean your boot times are significantly higher than if it was local. So maybe you shouldn't be looking for the same boot times that I'm seeing here. But hopefully you can get a better idea of whether the times you are seeing are related to the boot process, or what happens after the boot process. If you are seeing it in the boot process, then uninstall all 3rd party modules and test again. Or go one-by-one until you can narrow in on which one it is. If still seeing a slow boot then we might need to start looking at potential Windows platform issues. If your boot times seem reasonable, then the next step is to start debugging in the template files. Let me know what you find and I can suggest the next steps.

@cosmicsafari. Welcome to the forums and ProcessWire. You will need to include your Foo.php file in your module ( MyModule.module). ProcessWire doesn't know about it and will not include it for you. You can require it outside the class or in its __construct() or function init() methods (I think either of the three should work). $dir = dirname(__FILE__); require_once($dir . "/Foo.php"); Maybe it was just a typo, but module files end in .module (that's the extension, not .php)

The other day I saw a post about a one man passenger drone going to fly as a taxi in Dubai. You want it real cool ? Here you go: zapata one man flyboard with unbelievable manoeuvrability and portability. Many thought that this is faked with after effects or a hoax but this is for real. He developed this flyboard out of his huge expierience with his waterjet powered jetskies. Kerosine fuel is stored in his backpack wich gives about 10 minutes flight with max 90 mph This is the green goblin coming into reality One of his flights https://www.youtube.com/watch?v=deyMNPbaRpA Some explaining https://www.youtube.com/watch?v=x1CfhQnlZAU

Hello, If you go to "Edit", you should have a tab where the user can delete the page.

See my post Modulus operator - note that the style for the ul columns in this example is rough, but you should get the idea how it's done. foreach($page->children() as $i => $item) { if($i%3==0) echo '</ul><ul style="width:150px;float:left">'; echo "<li>{$item->title}</li>"; } echo '</ul>'; CSS Columns echo '<ul>'; foreach($page->children() as $i => $item) { echo "<li>{$item->title}</li>"; } echo '</ul>'; ul { -moz-column-count: 4; -moz-column-gap: 20px; -webkit-column-count: 4; -webkit-column-gap: 20px; column-count: 4; column-gap: 20px; }

Use the "Create Users Batcher" action in the Admin Actions module (https://processwire.com/talk/topic/14921-admin-actions/) .

Alternatively you could provide methods in your module, which return the needed markup when called from manually created template files.

I've been switching a site from using the Twig Template module to using the new Markup Regions and it's been fantastic! @ryan have you considered a placement attribute that will append/prepend/replace just the content of the attributed element, rather then the element itself? For example, my head tag is <head pw-id="head"> On one of my templates, I have some scripts and styles I need to append to the <head> <link rel="stylesheet" href="https://unpkg.com/leaflet@1.0.1/dist/leaflet.css" /> <link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.0.0/dist/MarkerCluster.css" /> <link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.0.0/dist/MarkerCluster.Default.css" /> <script src="https://unpkg.com/leaflet@1.0.3/dist/leaflet.js"></script> <script src="https://unpkg.com/leaflet.markercluster@1.0.0/dist/leaflet.markercluster.js"></script> <script src="https://unpkg.com/esri-leaflet@2.0.7"></script> As it stands I need to add pw-append="head" to every element: <link pw-append="head" rel="stylesheet" href="https://unpkg.com/leaflet@1.0.1/dist/leaflet.css" /> <link pw-append="head" rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.0.0/dist/MarkerCluster.css" /> <link pw-append="head" rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.0.0/dist/MarkerCluster.Default.css" /> <script pw-append="head" src="https://unpkg.com/leaflet@1.0.3/dist/leaflet.js"></script> <script pw-append="head" src="https://unpkg.com/leaflet.markercluster@1.0.0/dist/leaflet.markercluster.js"></script> <script pw-append="head" src="https://unpkg.com/esri-leaflet@2.0.7"></script> It would be great if I could wrap these with a <div> or similar, and use a placement attribute that would add all the children of the div, without adding the div itself. <div pw-append-contents="head"> <link rel="stylesheet" href="https://unpkg.com/leaflet@1.0.1/dist/leaflet.css" /> <link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.0.0/dist/MarkerCluster.css" /> <link rel="stylesheet" href="https://unpkg.com/leaflet.markercluster@1.0.0/dist/MarkerCluster.Default.css" /> <script src="https://unpkg.com/leaflet@1.0.3/dist/leaflet.js"></script> <script src="https://unpkg.com/leaflet.markercluster@1.0.0/dist/leaflet.markercluster.js"></script> <script src="https://unpkg.com/esri-leaflet@2.0.7"></script> </div> Or maybe this is already possible with some other technique I'm not aware of?

Preview of new Blog Dashboard UI coming in the next update... Posts List Quick Post (now in modal) Thoughts? Opposition ?

A stock PW3 installation should actually be faster than PW2 – it certainly is on all of my installations. There's a lot more optimization in PW3 than in PW2. If that's not what you are seeing, then it's time to start looking for where the bottleneck is. PW3 does not have more significant overhead than PW2 except when it is compiling a file for the first time. The 30% increase numbers mentioned above sound to me like that is a request where PW is compiling a file. You can expect a request where it has to re-compile a file to take longer. But it only has to do that once, when a file changes and needs to be re-compiled. Maybe that's a common occurrence on a dev site, but should be a rare one on a production site. I'm measuring here with Chrome dev tools, ProfilerPro and my own timers using the Debug class. What tool are you guys using to measure times, and in what quantity? Before deciding something is PW3 related, I really suggest testing with a basic/blank profile without other modules installed. If you are consistently seeing any kind of increase in render times under PW3, my guess would be that something is getting recompiled on every request for some reason or another, or that there is another module involved that runs slower under PW3 for some reason. Edit--A few things to add: Debug mode is going to be slower in PW3 than in PW2, simply because PW3 is tracking a lot more stuff than PW2 did. With debug mode off there should be no difference though. Keep in mind debug mode is for development, and not something you should ever leave enabled on a production site. PW3 is more efficient with resources than PW2. PW3's boot time (stuff it does before executing your template file) is 20% to 45% faster in my testing. PW3 executes 20% to 25% fewer queries as part of the boot, and loads up to 50% fewer pages. Autoload modules become part of the boot process, so I test with no 3rd party modules installed. The file compiler can potentially add a little bit of overhead even when it doesn't need to compile, because it has to determine whether something needs compilation. But on a default site profile we're talking about maybe 10ms at the most here. If you turn off the template compiler, then that overhead is gone. While PW3 uses fewer resources on the database side, but sometimes more resources on the file system side. If you've got a slow file system, you might notice it more in PW3 than in PW2. For those of you seeing PW3 to be slower than PW2, if it's determined that 3rd party modules are not a factor, I would be curious what's happening in the template files. Perhaps there is a bottleneck in a certain API call or something that we're not aware of yet. It would be interesting to see the results of profiling the API calls in your template files using ProfilerPro or Debug::timer() calls. Mostly specific to Soma: PW2 and PW3 are identical in terms of how they use joins and indexes. Regardless of version, PW will use as many joins as it takes to execute the selector you give it. Just like you can create complex or inefficient SQL queries you can also create equally inefficient $pages->find() calls if you aren't being careful. Using PW's API doesn't mean you are somehow bypassing the database. Your find() queries still become SQL queries. So if you are working on big and complex projects, then you need to watch and profile your work. When you a come across a complex find() operation that is expensive, refactor it to be simpler or break it down into smaller parts. Pay attention to how many pages you load in memory at once. Don't use find() and children() calls without "limit" selectors when dealing with potentially large sets. With regard to indexing, PW logically indexes all the columns that are likely to be used in find() operations, but if you are querying columns in a table have no index for whatever reason (3rd party module that forgot an index, or column not commonly used for queries), you may need to add one. Most of us never need to do this, but since you mentioned "big and complex" you may be in the territory where you have to apply more consideration to these things.

Last week we looked at progress on a new admin theme framework for ProcessWire. This week we’ll do the same, as development continues to move forward and we have a lot more screenshots to share (though keep in mind this is largely un-themed/stock). https://processwire.com/blog/posts/continuing-work-on-new-admin-theme-framework/

i want to say amazing. yes it was translation mistake I can order. But problem is your code it is not vertical column order.

You can accomplish this in two main ways - PHP via the modulus operator (google php modulus columns) or via css columns.

Sure a low quality image is better compressable (lots of same color values), but it's still 3888 x 2592 x 8bit x 4 (rgb + alpha) to just hold the image in memory. Maybe some other operation in the proces is memory intensive.

@chrizz your calculation is totally wrong. Only thing that is of interest for imagesizer is uncompressed image in memory. You do not hit a filesize limit, you hit a memory limit. Why you run into it, I can't say. But I can say that we do runtime checks for available memory before opening an image in memory, but also we use a fast calculation depending on most common images for that. Without seeing your original images, I guess your original image has some image markers like EXIF, IPTC, VENDOR-Tags etc. what may be a little over the top of what we use for our precalculation. Theoretically it is possible to pack a lot of data into this, but typically it isn't that big. Maybe an edgecase? (Calculation like we do, fits just into available runtime memory, but without the ImageMarkers?) But one thing is a physical fact: FilesizeCompression cannot reduce needed memory limit. (and therefor I do not need deep theory, this is simply how computers work since ever. In my earlier days, around 1994, we sometimes do some jokes: we compressed big dimensioned jpeg images with the lowest quality setting / highest compression rate, and send them as previews to Artdirectors with a question to them. Always when they tried to display it, it got loaded / uncompressed into memory and their systems imediately got freezed / unusable. So, we only have done that to very unfriendly people who really deserverd a little shock. ) So, what ever you have changed in your second saved imagefile, what is responsible for the fit into memory than, it is not filesize compression. A serious test would need to log the runtime available memory for both images before trying to open it, and the same after they allocated the memory, and compare all that. Also a full check of all file parts in the imagefile (markers and image data). Without that, it says null to nothing and only opens room for glasball looking, guessing or misinterpretions.

Hi, I think this is my first topic, even though I've been working with PW a few years. But now, I'm trying to restructure my way of coding, cause many templates (like activities for birding societies) are re appearing in multiple different websites. Since this, I've been working on redo this into a module, but as far as I have read I cannot store the templates (related to specific module) in the module's folder. It has to be in the templates folder?

That's just not how images work. You optimize the image size by using compression methods. But to manipulate (scale, …) an image it has to be decompressed first, so your optimization should in theory do next to nothing in terms of memory footprint. Also @horst already did his best to improve the image sizing tools as far as possible to detect memory exhaustion before actually hitting the limit. But there are just limits to what's detectable beforehand. P.S.: It's not advices to optimize source images at all, because the quality of thumbs will suffer (more than the compression did your source image)

No solution still, the only thing I've been able to do is to programmatically uninstall the SessionHandlerDB module. Now I've got again the access to the back-end.

This is so awkward, The issue was sorted out but i actually forgot to reply to this forum as i didn't get any notification. thanks

Another alternative could be having a "<parent />" element inside the "header", just like in template engines. This would be replaced with the header contents you have set earlier. You could use this element as the first or last one inside the header, or anywhere else. Because of such issues wrote I earlier that I find this approach similar to blocks in template engines. But if it's so, PW should borrow existing solutions from those.

Perhaps using indentation for nested fields could be more clear and space efficient instead including fields inside fields, what do you think? Or is such level of modification out of scope for now?

I agree. It's particularly a problem when using pw-after with multiple elements. To take a simplified example, if you have these elements... <p pw-after="header">First paragraph</p> <p pw-after="header">Second paragraph</p> ...you end up with your elements in reverse order... <header> <h1>My header</h1> </header> <p>Second paragraph</p> <p>First paragraph</p> You can't do... <header pw-id="header" class="pw-after"> <p>First paragraph</p> <p>Second paragraph</p> </header> ...or you end up with two headers. The workaround is to add your elements using pw-before on some other element. What would be helpful is some way to wrap all the elements you want to insert after without actually getting the wrapping element in the compiled markup.

We're going to be sticking with Font Awesome as our icon set. While Uikit comes with its own SVG icon set (and one certainly can use those) the scope and quantity of them is pretty limited relative to Font Awesome. Previous versions of Uikit actually used Font Awesome as their icon set, but in Uikit 3 they switched to their own set. There just aren't enough of them to cover our needs, plus I'd prefer to stay consistent with icon usage. So not planning to implement any features specific to Uikit v3 icons at this stage. As far as I know the Uikit cards aren't related to material design. They are a default styling that Uikit has for something that is visually offset in a different way. With the default styling that they've got, I've found the card view helpful when you get into nested Inputfield elements, as it makes it a little easier to visually identify the hierarchy vs. the completely flat look. I understand all-flat look is what's trendy right now, and my intention isn't to get into the design aspect at all. Though I appreciate that the Uikit folks recognize that there is a need for this kind of thing. So it'll be up to the people that get into the design side to interpret how one translates the card style in a Uikit theme. This one will also be open to interpretation in the actual theming process. I'm just trying to make the colors as obvious as possible at present.

In my opinion there are two sides to this problem: Many client's know WordPress and ask for it specifically, which in turn means that the companies building sites find it an easy product to sell. Even if the client doesn't know WordPress, they just need to be told that it's the most popular CMS out there. "You can't go wrong by choosing the most popular product in the market." Many web developers first dive into the CMS world via WordPress. Once they know it, it's tempting to use it for everything. Even if it's a struggle to create anything more complex with it, they a) don't know that there are better alternatives, and b) going with another system would require a whole lot of un- and re-learning. I try to advocate for ProcessWire every chance I get, mainly because I believe it's truly a great product, and fits many needs amazingly well. Obviously it's not for everyone, and in fact I have once or twice actually recommended going with WordPress instead. Funny you should mention this, as I was literally just today thinking about how the commercial modules fit the ProcessWire landscape, and once again came to the conclusion that it was a smart move from Ryan to make FormBuilder as cheap as it is. If you think it's "not very cheap", you probably don't really get how much it does for you Before Ryan released FormBuilder we were contemplating building our own form module, but just thinking about how many things such a module has to handle makes me shiver. It's a heck of a lot of work to build a module as flexible as FormBuilder, and making it easy enough for anyone with no technical expertise to build complex forms is not easy either. Agency license for FormBuilder is $289, and I can pretty much guarantee that building a module like that on your own will cost you at least ten times that amount. On the other hand we were considering buying another commercial module a while ago. The cost for a single license for that particular module turned out to be four digits, and eventually we decided not to buy it. I've been working on a module that matches our needs specifically, for a cost that is notably lower than we would've had to pay for the third party module. We're planning to release this particular module as open source when it's finished. It's true is that you generally can't add a completely new feature to a site, let alone build a new site from the scratch, without at least some basic dev skills. That's also not the market we're in. I think those who want to do that would be much better off with a DIY website builder platform such as Wix or Squarespace. This kind of thing is not really the forte of WordPress either – building a complex site from (sometimes) badly written, barely compatible plugins requires a whole lot of work, at least in my experience This depends on your definition of a "big company". Avoine is, in my opinion, the best example in this category – they've done some pretty amazing stuff with ProcessWire. Everyone in our line of work should know them, at least. I'm not an official spokesperson for my company so I prefer not to go into more detail, but at Fonecta we also use ProcessWire in some of our projects. You've probably heard of us before. If you're into command line tools, check out wireshell. Depending on your setup there are other solutions too, probably the easiest being the built-in multisite support, where multiple separate sites share the same core code.

I have also experienced this slowness for a while. Solving this issue should be at the top of the Roadmap for 2017 because of the effect it has on the SERPs and the User Experience. I think it's more important than new features or the expansion of existing ones. Today Processwire is so powerful and versatile, now should make a stop and solve this delicate problem before continuing to advance. What do you think guys ? Ryan?

A little help if someone has the same problem: images on develpment site were included, but not on live site. There is no error or any hint, but only a red "x" as placeholder for the image. Try to convert to base64 string included the image to the PDF. For me it even reduced the filesize $imagedata = file_get_contents( "../assets/img/logo-pdf-invoice.png"); // alternatively specify an URL, if PHP settings allow $base64Img = "data:image/png;base64," . base64_encode($imagedata);

You could just alter this to your needs. This adds a second button to the pageEdit, which then triggers an action if clicked. <?php class HookPageEdit extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Hook PageEdit', 'version' => 1, 'summary' => '', 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'addButtons'); $this->addHookBefore('ProcessPageEdit::processInput', $this, 'addButtonsMethods'); } /** * Add a button besides "Save", which lets the user accept the application * */ public function addButtons($event) { $page = $event->object->getPage(); if($page->template == "application"){ $form = $event->return; $accept = $this->modules->get('InputfieldSubmit'); $accept->attr('id+name', 'hook_accept_application'); $accept->class .= ' ui-priority-secondary head_button_clone'; $accept->attr('value', $this->_('Accept Application')); $form->insertBefore($accept, $form->get("id")); } } /** * Triggers the pageAction of "PageActionAcceptApplication" if the page was * submitted via the added button. This won't save the page, because that only * happens if the button is named "submit_save" or "submit_published" * */ public function addButtonsMethods($event) { if($this->input->post->hook_accept_application){ $page = $event->object->getPage(); $event->replace = true; if(!$page->id){ $this->error("Invalid application to be accepted."); return; } $accept = $this->modules->get("PageActionAcceptApplication"); $accept->action($page); } } }