Leaderboard

This week ProcessWire 3.0.217 is released with 10 issue fixes, 2 PRs and a couple of minor additions too. See the dev branch changelog for details. Recently a client called me in a panic because they'd spent a few hours making edits to a page, and when they finally hit save, they were no longer logged in, so their changes were seemingly lost. I guess that their IP had changed somehow, or they kept the page editor open overnight or something. Whatever it was, they were now sitting at the login screen with their changes apparently lost forever. Luckily this person left that window as-is and contacted me to see if there was any way I could recover their changes. I quickly edited their /site/config.php file and temporarily added these: $config->protectCSRF = false; $config->sessionFingerprint = false; Next, I asked them to open another tab and login there. Once logged in, they returned to the tab where the page save failed, then hit "reload" in their browser, and their changes were saved. Phew. Thankfully that worked, but if it didn't, the next thing we were going to try was to open the browser inspector "Network" tab, and then copy/paste the edited content right out of the browser's POST data and into the CKEditor HTML source window. I imagine this has happened to others and perhaps they weren't so lucky as to recover the unsaved changes. So how can you avoid this issue? The best bet is to just save your work regularly. But that doesn't always happen, no matter how many times we communicate that to the client. So you can reduce the probability of it by making a couple adjustments to your config.php file. One change would be increasing your $config->sessionExpireSeconds. But the default is already 86400 seconds (1 day), and I'm not sure many really take more than a day between starting an edit and saving it... though I'm sure it happens. Another change would be turning off the $config->sessionFingerprint (or loosening it, see fingerprint settings). That's trading security for convenience, which isn't ideal, but it would prevent a changed IP address from expiring the session. Another thing you can do is install the ProDevTools UserActivity module, which keeps a ping going to the server, preventing you from getting logged out due to inactivity. Though this doesn't prevent a changed session fingerprint from logging you out, though it at least alerts you as soon as you've been logged out. Even the above changes might not completely solve this issue, and I don't like to tailor session settings around this case either (reducing security), so I've been thinking of alternatives. After dwelling on it for awhile, I started working on a module that saves non-authenticated POST requests sent to the page editor... saving data that would otherwise get lost. Then when you go back to edit the page, it alerts you that there are unsaved changes and asks you if you want to save them. When you answer yes and hit "save", it repopulates the unsaved POST data back into $input->post before the page editor has had a chance to process it. There are of course some security considerations here, so it has to be built carefully. I should also mention that it won't help much if it's the client's computer or browser that has frozen (there's the PageAutoSave module that can help with that). Though data loss due to a frozen computer/browser is likely even more rare than session loss. I don't have this module fully working just yet (it's a work in progress), but it's relatively simple so it probably won't take long. It's not going to catch everything; it won't save files, for instance. But it will catch the most likely cases, such as changes to those big "body copy" fields that someone might spend hours making edits with. I'll post more about it when I've got it a little further along, if there's interest. Thanks for reading and have a great weekend!

https://warp-design.co.uk/blog/why-we-love-processwire/ https://dotnetic.de/blog/processwire-the-best-cms

Hello @Boost, have you seen this page: https://processwire.com/about/wordpress-vs-processwire/ ? ? Regards, Andreas

Sure, there is. As always :) Thanks in advance. Have a great weekend everyone!

ga beer -- u.try this in home.php ? if ( $input->urlSegment1 === 'files' ) wire404();

I've just released a new version with a ton of updates ? https://github.com/baumrock/RockMigrations/releases/tag/v3.25.0 I started to adopt a new workflow, because I often heard that "it's hard to keep track". That's why from now on I'll push updates to the dev branch and then merge them to main from time to time. Highlights: I improved the deployment log a lot, made everything a lot cleaner and tried to catch all the warnings that where just written to the log before. Old: New: We also have a new tweak to show page ids in the page tree (1) and a helper method to add labels in the page list (2) and also the template name (not in the screenshot) Check out https://github.com/baumrock/RockMigrations/releases/tag/v3.25.0 for all updates!

Purge the StackPath CDN cache when ProCache clears. https://github.com/nbcommunication/ProCacheStackPath If you use StackPath's CDN to deliver your website, you need a way to clear its cache when ProCache clears. This module connects with your StackPath stack via the StackPath API and when ProCache clears it requests StackPath clear the cache, attempting to respect the specific rules (Parents, Family, Children etc) set up in ProCache. This module is being using in production but only for a couple of sites that just clear the whole cache when a page is saved. The implementation of the Parents / Family / Children rules haven't been fully tested, and it isn't clear from StackPath's documentation whether their 'recursive' option only works from the root URL or from internal pages too. Hopefully it does and I'll hopefully get it tested soon. Cheers, Chris

Hello, I'm planning to introduce PW to my boss and persuade them to choose PW over WP. Do you have any articles, posts, or presentations that I could use to support my argument? Thank you.

Synchronises ProCache clearing across a multi-instance environment. https://github.com/nbcommunication/ProCacheSync The main purpose of this module is to allow ProCache to be used in an auto-scaling multi-instance environment. How it works When a page is saved and cache clearing is triggered, the page id(s) associated with that clear are saved to the database. ProCacheSync runs a check every minute via LazyCron to look for records in the database since ProCache was last cleared. If it finds any it processes them as ProCache would. Any records it finds will have been generated by a clear on another server instance, thus enabling multiple instances of ProCache to stay approximately synchronous. This module is not yet being used in production. Cheers, Chris

Thanks to everyone for your valuable input. Here are my findings after having tested this on a fairly virgin multilang install with root URL in default language redirected to /en/ through LanguageSupportPageNames setting and URL segements enabled on the home template. After putting in anything in the URL segment whiltelist, the URL hook works. And of course, like @bernhard suggested the regex option makes total sense. Great idea if you control behaviour from within the template file. And this also proofs that URL hooks are kicking in right befor showing the 404 page. I enabled all segments by leaving the whitelist empty. Then in my PageView::execute hook, that handles display of pages by URL segment, I am throwing a 404 with `throw new Wire404Exception();` This throws an Exception and doesn't show 404 or execute my URL hook. Seems like we can use wire404() or throw new Wire404Exception only in template files? My hook is triggered inside init() of an autoload module. My conclusion: if you have URL segments enabled on the home page and want a URL hook to execute, you need to have a whitelist for URL segments defined. Thanks again to everyone. Now if you can tell me how I can throw a 404 without getting an Exception in my autoload module, that would be awesome ?

Depending on how you're handling unrecognized URLs, this could be a feature (sort of). If you enable all URL segments and don't throw 404 with the Wire404Exception::codeFunction code (or via wire404() function), no further hooks will (or should) be executed. See wire404() function docs (and/or function definition) for more details. ... though if you're already handling them as described above, then it's likely a bug ?

Hey @protro that's strange - why should it find the woff file as changed file if it didn't change? Though you can customize livereload to your needs like this: $config->livereload = [ // interval to watch for changes 'interval' => 1, // 1s = default // user defined include paths 'include' => [ '.*/foo/bar', ], // you can reset default include paths 'includeDefaults' => [], // user defined exclude regexes 'exclude' => [ '.*/site/my-ignored-folder', ], // you can reset default excludes 'excludeDefaults' => [], ]; I might exclude /site/assets entirely one day ...

Sounds like a bug to me and might be worth creating an issue on github? Other than that: Have you tried limiting allowed url segments via regex? Just tried with a regex that allows all url segments except ones starting with "test" and it worked: regex:^(?!test).*$ In home.php bd($input->urlSegment1); And the hook in init.php: $wire->addHookAfter("/test/{file}", function ($e) { bd($e->file); }); /foo/bar/ --> shows "foo" /test/foo.jpg --> shows "foo.jpg"

That's a great writeup! ?

If you are only handling a limited number of images you can also use RockImagePicker: https://processwire.com/talk/topic/27677-help-suggestions-on-reusing-a-background-image-across-a-site/

I've decided that for my use-case, a better solution is to have a 'resources' page and template, and a 'resource' template which has a singular file field and use one page per file. Then to use page reference fields to include that in actual visitable pages. This enables me to include an image field for my files, as well, of course as all the other fields I need for files.

Hey @RIC Developer Thanks for the suggestion, makes sense to me. Latest version (1.10.0) of the module has a specific setting for allowing/disabling removal of rows. Additionally settings (all of them) can be defined in site config, in which case they are no longer editable in module config: $config->ProcessLoginHistory = [ 'allow_remove' => 0, ]; Note that there was already a separate (optional) login-history-remove permission: if this permission exists, it is required in order to remove rows. This was undocumented, but I've added a separate permissions section to the README.

Thanks for reporting @gebeer. Added to my TODO.

Just released the updated version of the german language pack for the just released stable core version 3.0.210 Download ZIP (github.com) @ryan @teppo

Your link to my example is wrong - I guess you mean this one ? The main advantage of using constants is not about being able to change names (as that happens almost never) but to get better structure into your code and also get additional information that you do not get from regular strings or object properties. And I'm using it a lot with array syntax but you are absolutely not limited to that! And you cal of yourse always use class constants in strings: $pages->find("template=".Foo::tpl); But here are some very simple examples why I'm using that approach in the first place. Imagine you wrote code 1 year ago and look at it to fix a bug or add a feature. Compare those two: // example migration $rockmigrations->createField("type", ['type' => 'text', 'collapsed' => 2]); // example find $pages->find("template=animal,type=1|2,category=3|4|5"); // example migration $rockmigrations->createField(Animal::field_type, [ 'type' => 'text', 'collapsed' => Inputfield::collapsedBlank, ]); // example find $pages->find([ "template" => Animal::tpl, Animal::field_type => [Animal::type_cat, Animal::type_dog], Animal::field_category => [ Category::small, Category::medium, Category::large, ], ]); Or with better syntax highlighting: Imagine you had to answer these questions: where (to which pages or logical parts of your app) does the "type" field belong to? which animal-categories am I listing with my page find operation? what is the collapsed state of my Inputfield? Which of the two code bases above would you want to manage? ?