PW 3.0.217 – Core updates

[ryan]

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!

[szabesz]

1 hour ago, ryan said:

if there's interest.

Sure, there is. As always :) Thanks in advance.

1 hour ago, ryan said:

have a great weekend!

Have a great weekend everyone!

[Kiwi Chris]

5 hours ago, ryan said:

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.

My approach to this is non-web based. I write my copy in LibreOffice, and then copy and paste. Unlike Word which has a habit of generating horrible HTML code, LibreOffice generates clean HTML when copied and pasted, as long as you stick to using formatting that exists in HTML, ie headings 1-6, lists, and paragraphs.

Since LibreOffice is free, and uses .odt file format by default whereas Word uses .docx it's possible to have both, and use LibreOffice Writer for web content.

An .odt file is just a zip file containing XML and any visual assets (as is a .docx file) (You can test by changing the extension to .zip and then open the file. I've used this technique to get jpg files for a website when someone's emailed me a Word document.), so in theory, it should be possible to write an import module to upload an .odt file, read its contents, and save to a rich text field in ProcessWire. 

I'm happy copying and pasting from LibreOffice Writer, but an automated import module for people who write a lot of rich text and need to get it into ProcessWire might have merit for others.

[MarkE]

15 hours ago, ryan said:

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?

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. 

[BrendonKoz]

On 5/6/2023 at 5:59 AM, MarkE said:

Just a simple message to say you’ve been signed out would help.

Yup. When I was experiencing issues on a simple form (unrelated to ProcessWire) that people were spending an inordinate amount of time on, I ended up using JavaScript to send simple, periodic requests to the server to determine authenticated status. If the session timed out, it alerted them of that fact, and urged them to copy/paste their data to be safe (even though it was saving to a draft field regardless). It helped cut down on complaints tremendously; the only ones remaining were, "It should never log me out if..." and that took more explaining than solving. 😉

Thankfully PW already has some good solutions in place for these scenarios. Anything in addition to what already exists would always be welcome. It's never fun to deal with clients/coworkers in a panic. Thanks, Ryan!

[MeganMarden]

On 5/5/2023 at 11:37 PM, ryan said:

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!
 

Thanks Ryan 🙂

[monollonom]

Quick message to say the small tutorial literally saved me just now. I'm going to install the module asap and get back to working. Phew