ryan

This week we’ve got lots of details on our successful migration to Amazon AWS services for the processwire.com network of sites. We've also got updates on the current core and ProDrafts status. https://processwire.com/blog/posts/amazon-aws-now-powering-processwire.com-sites/

This week we've merged the dev branch to the master branch for ProcessWire version 3.0.61 master. This replaces the existing master version 3.0.42. What's the difference between 3.0.42 and 3.0.61? Quite a lot! In fact, we might usually call this a major version and just name it ProcessWire 3.1, but we're saving that version number for when we get at least the new Regular site profile included (and perhaps the new admin theme), after Uikit 3.0 is out of beta. In this post, we'll cover some of what's new with ProcessWire 3.0.61 relative to the previous master version… https://processwire.com/blog/posts/processwire-3.0.61-master/

Thanks–fixed. The API reference is already showing all the docs available for each method, so linking to line numbers would focus in on the actual code/implementation behind the method, rather than the documentation. When it comes to docs, it's about the interface, not the implementation. The interfaces rarely change, whereas the implementations change all the time. Coding towards something other the method's interface could be problematic. That's why I think the code-behind-the-method probably shouldn't be part of the documentation, except maybe in cases where the docs suggest looking at the method directly. This refreshes once every 24 hours. This is not intended, I'll fix this–thanks. Btw the "c=" indicates number of changed fields when possible, but mainly c=0 means no changes, and c=1 means there were changes.

This week we have ProcessWire 3.0.60, which is likely to be our next master version. We’ve also got a few more Pro module updates, as well as a major update to our online API reference… https://processwire.com/blog/posts/processwire-3.0.60-core-updates-and-more/

The latest core dev branch coming soon to the master branch, plus several Pro module updates and more. https://processwire.com/blog/posts/processwire-3.0.59-module-updates-and-more/

While mostly just routine updates, this week we have a new core version on the dev branch with several tweaks and PRs. Work also continues on the Uikit admin theme framework, and more: https://processwire.com/blog/posts/processwire-3.0.58-core-updates/

This week, some more layout options have been added to it that I think many may find useful. This post highlights them with a screencast: https://processwire.com/blog/posts/processwire-3.0.57-and-admin-theme-framework-updates/

This week we have a new core version on the development branch and some nice updates to our Uikit admin theme in development. This post covers them in detail, includes a screencast and links to a live demo of the updates. https://processwire.com/blog/posts/processwire-3.0.56-and-uikit-admin-theme-updates/

This week we’ve got a new core version on the dev branch (3.0.55). This version has a whole bunch of fixes and adjustments. It also adds a new drop-down page tree that we cover in more detail in this blog post. https://processwire.com/blog/posts/processwire-3.0.55-core-updates/

No problem – I've updated the "regular" demo site to use this latest version of the admin. It's not all that different from the one that was there, but does have the new offcanvas nav and several other minor tweaks that weren't present before. If you check it out, and you checked out the previous iteration, you probably want to clear your cache or login with incognito mode, as the demo site has some aggressive cache control headers and I neglected to update the css/js version links. http://demo.processwire.com/regular/processwire/ u: bloguser p: processwire3

Last week’s post indicated we may have the first [beta] version of the Uikit admin theme ready, and I’m glad to report that we’ve now got it ready for download on GitHub. In this post, we’ll describe what’s new, how to install it, and how to develop with it. https://processwire.com/blog/posts/processwire-3.0.54-and-adminthemeuikit/

@vwatson I was able to duplicate this issue when selecting text in a <td> and dragging the selection a little bit past the actual text. What I found is that you've got to be really careful with the link selection in a table cell, or else CKEditor will include part of the <td> element in the selection. The result is that when inserting a link of that selection, you get an invalid link, which isn't allowed there, so CKE moves it above the table. So far I can't figure out how to automatically modify that selection to narrow it in, but I did figure out how to detect it and cancel the action. I've also set it to show an alert box telling you to re-try the selection. This at least prevents the insertion of the invalid link. Please replace your /wire/modules/InputfieldCKEditor/plugins/pwlink/ directory with the contents of the attached ZIP file. Do you find this also resolves the issue there? Thanks. pwlink.zip

This week we've got a demo setup of the admin theme framework that's been written about in the last two weeks of posts. Read all about it here and try it out from our demo site– https://processwire.com/blog/posts/demo-of-admin-theme-framework/

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.

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.

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.

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/

This week we’ve started developing a new admin theme for ProcessWire that aims to be a community collaboration. We’ve now got some good momentum with lots to share in this post. We also get into some technical details and have screenshots as well. https://processwire.com/blog/posts/working-towards-a-new-admin-theme/

This week we give extensive coverage on how to optimize 404 requests in ProcessWire. In this post you’ll learn about why 404s are significant issue, and then we’ll look at what you can do to optimize and ensure your site doesn’t waste valuable time and resources serving irrelevant crawlers and bots. This post also briefly covers this week’s core version 3.0.52. https://processwire.com/blog/posts/optimizing-404s-in-processwire/

http://duckisland.com/GreekMachine.php

Consistent with the plans of introducing new site profiles this year, we’ve started work on the new site profile, and have the first version ready this week. This profile contains a blog component and uses the new Uikit 3 front-end framework: https://processwire.com/blog/posts/introducing-a-new-processwire-site-profile/

This week's version of ProcessWire expands upon our markup regions support introduced last week, and also contains various minor fixes and tweaks. In addition, it adds a $urls API variable which is simply a shortcut to $config->urls. But since this is so commonly called upon, the shortcut can be useful in reducing verbosity in some template files. Meaning, if you want the URL to /site/templates/, you can now use the shorter $urls->templates rather than $config->urls->templates, if you'd like. This also adds consistency with our recently introduced urls() function that's part of the optional Functions API. https://processwire.com/blog/posts/processwire-3.0.50-core-updates/

It's such a small simple module that I think your best bet is just to edit it directly, and perhaps rename it (to avoid it potentially getting overwritten in the future). Remember to rename both the filename i.e. TextformatterMyVideoEmbed.module, and the class name to match. Then do a Modules > Refresh, and install it.

This week we take a look at a new template file output strategy available in ProcessWire 3.0.49+. (Not to be confused with a “template system” like Twig or the like, as our template system is PHP). This strategy is an experimental but super-simple new alternative to direct output and delayed output, and in some ways a combination of both. Yet it’s likely to be more accessible for front-end developers and newcomers to ProcessWire, without sacrifices. Have a read and let us know what you think. https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/

This post includes coverage of the latest weekly core dev version, an update on ProDrafts, and more. It's a bit of a short post this week due to a change in schedule today, so some of the planned content for this week will be in next week's post. https://processwire.com/blog/posts/processwire-3.0.48-core-updates/