Leaderboard

Sounds like it would be a good case for a custom Page method (either added by hook or by custom Page class) that falls back to the core $page->get() when no value exists. $value = $page->getFromJson('some_field');

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!

Robin’s suggestion of using a custom page class should work for that, just override get(): <?php namespace ProcessWire; class DefaultPage extends Page { private $cache = [ 'title' => 'look at me. i’m the title now.' ]; public function get($key) { return $this->cache[$key] ?? parent::get($key); } } IRL you may want to add logic dealing with output formatting and what not, but that should be a complete working example. Unfortunately get() is not hookable, so I don’t believe this can be accomplished in a module. That said, have you investigated other avenues? Why not cache the whole markup and be done with it?

@FlorianA I know your question is a bit old, but I just recently had to do this and below is how you get the form data. In my case, I put it all in a custom module. Gets called after an update is made at /admin/profile/ public function init() { $this->pages->addHookAfter('ProcessProfile::execute', $this, 'sendOutProfileNotification'); } public function sendOutProfileNotification(HookEvent $event) { $event = $event->object; //form data is found in $data = $event->return; //do something with data here is data is not null. } Hope that helps.

I think you likely upgraded from a very old version of Tracy at the same time you upgraded to PHP 8. When you saved Tracy's config settings, that adjusted the value of $this->data['styleAdminType'] thereby fixing the error.

Maybe you can hook Fieldtype::loadPageField()? https://github.com/processwire/processwire/blob/6ff498f503db118d5b6c190b35bd937b38b80a77/wire/core/Fieldtype.php#L1108

Version 1.2.3 is ready! PLEASE DEINSTALL THE OLD VERSION OF FRONTENDLOGINEGISTER AND UPGRADE FRONTENDFORMS TO THE LATEST VERSION BEFORE, BECAUSE THERE ARE A LOT OF CHANGES AND NEW FEATURES!! OTHERWISE YOU WILL GET ERRORS! Beside fixing a lot of bugs, this new version supports upload for an user image too. Supported Fieldtypes for images are FieldtypeImage and FieldtypeCroppableImage3. Please note: You can only use ProcessWire image fields with single upload - multi-upload fields will be ignored and cannot be selected. So if you want to use an existing image field or you need to create a new one, take care to set the image upload only to 1 single file. After you have added this field to the user template, you can select this field inside the module configuration and add it to the profile form and/or to the registration form. Take also care that this field is editable by the user, otherwise it will also not be selectable. Just to mention: Technically you can add as many image fields as you want to these 2 forms, but it would not make sense, because each user needs only one image. But if you want.... you can. There were a lot of changements taken, so please let me know if you discover issues. Best regards

Kosheen... almost an Oldie/Classic now.

I’ve found that the most irritating situation is when the editor leaves a page open, then comes back to it some time later and makes a big edit only to find it won’t save because they’ve been signed out. The UserActivity module fixes this nicely, but it would be better if it was fixed in the core. Just a simple message to say you’ve been signed out would help.

Big fan of the implementation of this. I was still using soma's Module Manager with a quick hacky fix for the lack of pagination support. I am having an issue, however - when selecting the "Show All" category, it just shows nothing. Permanently. From what I can tell, it's not even sending an XHR request which is probably part of the problem. ? (For reference, I'm using PW version 3.0.158 dev) If that could be fixed, it would basically be perfect, imo. Edit: And I do agree with @Peter Knight about using a select rather than radio, and "Active" and "Inactive" seem to have more obvious meanings than "show only uninstalled", imo.