Lost Work -- Auto Log Out misery: help me understand what happened?

[Metadope]

Hi all,

I screwed up. I just lost a few hours of writing work, and I'm undertaking to understand how and why, and looking for some PW-specific tips on how to prevent this from happening again.

I am serving PW 2.5 via Nginx on an AWS micro-site.

I was editing the About page (having launched my site (http://Metadope.com) with a slightly modified Example template).

I took a long time editing. I wrote a lot of carefully crafted sentences.

I was using the default Admin template that ships with PW.

When I hit Save, however, I was prompted to log in again.

After submitting to the new login prompt, I was horrified to discover that all my edits were gone, and there was no getting them back. The Save had been refused, the edits discarded.

I'd like to edit the ProcessWire session timeout so this never ever happens to me again. Can I do that? There's no obvious setting available in the Admin interface, so a that-a-way pointer from more experienced PWers would help.

Without changing the default session timeout value (which is what?), I'd also like to understand how the edits were lost in the re-authentication flow. Did ProcessWire drop the ball (new code needed in the session-timed-out handling of a pending POST request)?

Or is this something that failed me in my server configuration (Nginx and php-fpm, or mySql)?

Any help (or commiseration) is appreciated.

[horst]

Sorry to hear this, - but despite this unfortunate fact: welcome to the forums.

All settings can be seen in the wire/config.php, but please copy those you need into site/config.php and edit them there. (settings in wire/config.php are the defaults, individual custom settings goes into site/config.php, so they are save on upgrades and / or can be detected & collected by site exports, etc.)

And, yes, now you know it, more often saving (also if needed without publishing a page) is better. And besides that, I use a Plugin with my browser (FireFox) that stores all textarea inputs for a configurable time: https://addons.mozilla.org/en-US/firefox/addon/textarea-cache/

This I do because I run into the same situation some time ago, ;-)

[diogo]

Sorry to hear that

There's nothing like writing in a offline editor and pasting it to the textarea for publishing. Or a browser extension like Horst said.

[Metadope]

Okay, I'm recovering.

And, I've found the first part of the answer I was looking for. The session timeout is set in the config.php file (and now don't I feel even dumber than I did before), and it defaults (in PW 2.5) to 24 hours, which is a sane default. I knew that. I just forgot. 

I left my Admin session open overnight, got timed-out, and lost my work.

I've learned this same lesson once before, in other online editing sessions. Never hit save or send a Post until I'd first saved (cut and paste) a local copy (because POST requests fail, for a variety of reasons, and Javascript-based editors are not robust). That's my habit; I was rushed today.

But I sure would love to solve this problem once and for all.

It is just so counter-intuitive to have to keep remembering that Save means Lose, sometimes.

Is there anything I can do with ProcessWire to solve this problem? Maybe a client-side bit of JS to auto-save for the editor, or a session-timed-out message box.... or, other server-side intervention, like creating a temp JSON representation of the refused POST, to be reprocessed after re-authentication...?

[Metadope]

@Horst, thank you for the link to the Firefox add-on. As just a user who has suffered from POST fails in the past, that's a very useful tool to add. And, thanks for the forum welcome too.

@Diogo, yes, thank you, I do usually work that way, simple Notepad or TextEdit local, then cut-and-paste and Send. Live and re-learn.

[tpr]

Though not a safe workaround but I usually hit ctrl+A followed by ctrl+C before hitting Submit. This of course works only for textareas, not multi-field forms.

Here is a recommended topic for you:

https://processwire.com/talk/topic/1818-ajax-save-google-docs-save/

[Christophe]

Perhaps this could be useful, in this case or in another one...: www.seleniumhq.org (browser automation).

[Metadope]

@tpr, thanks, that leads me down the path to diogo's old post about Sisyphus.js, which I can integrate into my version of the default Admin template code.

I do feel like Sisyphus today. But this trip up the hill, I'm learning, I'm learning...

[Christophe]

It seems ready for CKEditor:

http://sisyphus-js.herokuapp.com/#interaction

Interaction with other plugins

Let's add some fanciness to our form's textareas via CKEditor

// What's going on here?
// Here we'll persist the form's data into localStorage on
// every keystroke
$( function() {
$( "#ckeditor_form" ).sisyphus()
} );

[diogo]

Guys, I implemented sisyphus.js as a module. You can test it from here https://github.com/ocorreiododiogo/Local-data-saver-Processwire

To test, edit one or more fields in a page and open that same page in a new tab without saving. The data should magically appear there

I didn't test it thoroughly, so, proceed carefully. In this implementation, all changes will be saved to local storage until the from is submitted. after submission the local storage is cleaned. Ideal implementation would have a visual clue that the data was loaded from local storage, and not from the db, and would have a button to clean the local storage and replace it with the real data.

PS: I can see some cases where this can cause confusion with multiple users, but currently it can also happen without the module.

[diogo]

Just noticed that Sisyphus doesn't identify the pages as different, because it doesn't distinguish between different get parameters. They are all the same url for the plugin, so the data passes from page to page. Shouldn't be too hard to add an extra check, but I can't do it anytime soon.

Again: don't use this in production websites! 

[Soma]

I made a module back then... https://github.com/somatonic/AutoSave

[diogo]

Soma, that's a different thing of course. But I think you know that

So, the problem above is partially solved. I only had to add one setting to sisyphus locationBased: true to tell it not to ignore the get values. Of course now ?id=2767 is different from ?id=2767&s=1, but this was just a quick fix.