Leaderboard

Following up from the module mentioned last week, the PageEditRestore module has been released and here's a new blog post with all the details. This module helps to prevent page edits in the admin from getting lost when the user’s session is lost— https://processwire.com/blog/posts/page-edit-restore-module/

If you end up writing something with github action / webhooks / etc to automate things on a staging setup, and rockmigrating rolling back if your written test cases fail, please do not hesitate to share it with us (I am not sending subliminal messages) ? I would like to be able to give you more likes ??

This is brilliant! Just minor tweaks. You already did 99,9% of the job. Awesome! Thank you. wire()->addHookAfter("LazyCron::every4Weeks", function(HookEvent $event) { $checker = $event->modules->get("ProcessWireUpgradeCheck"); if(!$checker) return; $upgrades = $checker->getModuleVersions(true); // we only want modules with new versions if(!count($upgrades)) return; $subject = "There are " . count($upgrades) . " modules to update"; $body = "Hi!\n\nAn upgrade is available for these modules on " . wire('config')->httpHost . ":\n\n"; foreach($upgrades as $name => $info) { $body .= "- $name ($info[remote])\n"; } $body .= "\nHead to " . $event->pages->get("process=ProcessWireUpgrade")->httpUrl . " to upgrade."; // not sure if this `get` would work? $mail = wireMail(); $mail->from("wwwuser@example.com") ->to("admin@example.com") ->subject($subject) ->body($body) ->send(); }); Just added this to an existing site. Works perfectly fine. Follow up Added public recipe for all: https://processwire.recipes/recipes/automate-module-upgrade-check/

Based on my recent post and your answers in Module: ProcessWire Core Upgrade I decided to no longer hijack that thread and therefore open this one. @bernhard asked some very good questions there and here are some of my answers. First and foremost, I keep all of my "Automation Hooks" at /site/ready.php, and they are not present in all of my projects. I mostly utilize them in larger long-term projects and projects in which I have devoted a significant amount of effort - see samples below. I considered building a module for each project so that I could keep it around, fork it, alter it... that kind of dev approach. But that didn't work out as expected, so everything was moved back to ready.php - which actually works best for me. One file in plain sight, right next to everything else. For these activities, I have my own collection of snippets. I simply grab the appropriate snippet, tweak it, position it, test it, and proceed from there. No overly complicated workflow at all. But why should I care if there are any module changes (see thread above) if I'm not going to update them right away? I'm curious about what's going on in each project. I can see which modules were installed, which are in use, and which may be upgraded the next time there is a release. I rarely update modules or anything else outside of my development environment. I learned my lessons here. This isn't something I'd use in a project in which 99% of the code consists of echo/foreach like in some smaller sites I built. I honestly don't care because their code base and modules will almost certainly never be touched again. Projects like these are a totally different thing - some of those "Automation Hooks" are in place there: What things I "automate" and have in place across my projects - to give you an idea why this makes my life easier. Checking for news updates (weekly) No updates in the last 2 weeks? Remind the client to say something on their website and suggest doing so on social media, Google Business, and everywhere else too. Checking event count (weekly) Only 3 events left? Tell the client to check this and update the event pages or at least post something in the news to tell visitors what's going on. Checking newsletters (weekly) No newsletter in the last 2 weeks? You get the deal: the client will be notified to either send a newsletter or hand out content so someone else can do this Checking lunch deals (daily) Same as above. A restaurant runs out of lunch deals and will be notified via email right away. Archive old stuff (weekly) Short term content, like lunch deals, don't have to stay in there until the end of days. Archive them under another branch of pages, delete/trash them. Out of sight, out of mind. Checking for TODOs (weekly) This is a special one as I sometimes like to add a notes field to content pages in which I can write down things I need to do on that specific page in a project. I look for all pages having content in this field, put everything in a mail and go from there. It's something like a TODO app but direct in the project. No Jira, Asana, Todoist needed for this. There are plenty other options available. In my situation, it varies depending on the specialty, the project's budget for maintenance, or the overall scope of my tasks. I typically utilize these "Automation Hooks" to learn more about a project and remain informed. Sometimes it's for the client, but it's all automated. There have been projects performing comparable automated tasks for over a year now or more, and the customer is thrilled to receive an email every now and then with a list of things he should do. WINNER WINNER! I get paid to remind him, and he gets things done. You could put anything you wanted in those. File counts, database size, login errors, PHP version, PW version, and so on. Ping at @flydev @monollonom @horst

@szabesz The roles/users/templates part would be possible. But for someone that has access to the page editor, is there any reason not to give them access to save/restore something that they lost? The tool doesn't give them the ability to restore any fields beyond what they already have access to. I guess I see it as something that ideally wouldn't be limited by access control since it's a tool to prevent lost work, rather than a tool providing any kind of enhanced access. Though maybe there are use cases I haven't considered yet. As for deciding what fields should be restorable, that part is a little more tricky because it doesn't actually have any idea what fields it's saving or restoring. It's not actually saving or restoring fields. Instead, it's saving and restoring the raw POST data from the request. It would be easy to identify a TinyMCE field named "body" in the POST, but it would be quite a bit more difficult to identify the the same field within a repeater or other more complex type. If it offered the ability to select which fields it can save/restore, then it would have to know the POST data naming conventions used by all of the fields and subfields within them. This is where it would get significantly more complicated to configure and maintain, and more prone to bugs. Whereas now it just simply restores your lost POST request, providing the same result as if your "Save" had worked, rather than failing due to session loss. It doesn't have to know what all the variables in the POST request are for, so by just saving/restoring it all, there's very little chance for the module to screw up anything.

1st thought: Wow, that is brilliant!!! 2nd thought: We have to build a module from/for that!! 3rd thought: Hm... How would I actually use it. What fields would we need to have? Would I actually want to update, just because there are updates? Isn't it actually more dangerous to update modules than to just leave them untouched? I mean - I'm also keeping all modules up to date usually, but in general that happens during development so I'm hands on that project and I instantly see if something breaks. So how are you thinking to use that @wbmnfktr and others? I'm also happy to read about RockMigrations, though I wonder if the use case would be a good one for RM... It's actually built more for the opposite of reverting changes. It's really good add adding/changing things, but I'm usually reverting things just by git reset and/or "php rockshell db-restore" I really like the idea of having some kind of PW Assistant (or copilot) that notifies the admin about important things. It would be to define thought what those important things could be. I could think of several things like monitoring file count, file size, db site, file permissions etc. of an installation. Maybe also a 404 monitor or such. Maybe I'm already too many steps ahead, but I think if I really wanted to add something like this it would need to be something really useful and just updating for the sake of being up to date is just not enough for me ? Edit: Related: https://processwire.com/talk/topic/28499-automation-hooks-make-life-easier/#comment-232765

It wouldn’t be too difficult using ProcessWireUpgradeCheck::getModuleVersions. You can also have a look at ProcessWireUpgradeCheck::loginHook to see how it's used. Something like: $wire->addHook("LazyCron::everyMonth", function(HookEvent $event) { $checker = $event->modules->get("ProcessWireUpgradeCheck"); if(!$checker) return; $upgrades = $checker->getModulesVersions(true); // we only want modules with new versions if(!count($upgrades)) return; $subject = "There are " . count($upgrades) . " modules to update on $config->httpHost"; $body = "Hi!\n\nAn upgrade is available for these modules on $config->httpHost:\n\n"; foreach($upgrades as $name => $info) { $body .= "- $name ($info[remote])\n"; } $body .= "\nHead to " . $event->pages->get("process=ProcessWireUpgrades")->url . " to upgrade"; // not sure if this `get` would work? $mail = new wireMail(); $mail->from("upgrade@$config->httpHost") ->to("you@mail.com") ->subject($subject) ->body($body) ->send(); }); (non tested code written from my phone, so please forgive the formatting and/or mistakes ?)

Good work, @bernhard! Reading those links linked above made me smile... especially the pig-with-wings vs. panther analogy from Ryan ? "but we don't want a pig, we want a panther" - someone pls make a meme anim. GIF, or a T-Shirt please ?

Thanks for the detailed reply! I see now that such a feature would not be feasible. You must be right. I was just wondering if it is always a good idea to let the module kick in no "matter what".

Thank you Ryan, reading the blog post I have one question: is it possible to somehow create a white/blacklist of roles/users/templates/fields so that we could fine tune when the restoring the operation should be offered in the first place?