Occasionally, WordPress will log you out while you’re creating content. If you’re using P2, the AJAX polling code will give you a popup indicating that you’ve been logged out (and locks your ability to post a form).
Within the admin however, you can hit “Save Draft” and WordPress will redirect you to the login. This means you’ve lost all of your content. If you’ve been logged out for a while too, WordPress hasn’t been autosaving.
It would be nice to bring that P2-style notification to the admin.
12 Comments
When the autosave triggers, doesn’t it then display the red error box?
I don’t believe so, but I haven’t looked at the code yet. In my experience (and based on the experience of others), auto-save isn’t that reliable.
Regardless, a more obvious alert and blocking the ability to save the post would be a nice enhancement.
This has been an issue for us. It does trigger a red alert box, but nobody notices it.
+1 and I created an enhancement ticket for you:
* http://core.trac.wordpress.org/ticket/20599
This can definitely be very frustrating, but can be very rare. Autosave does check if cookies are on their way out, and cookie validation does check if, on a POST, a cookie has been expired for less than an hour (at which time it implements a grace period).
There have been some efforts to make things more obvious (outside of #20599), such as via #19120, as well as more automated (we’ve discussed ways to automatically extend the cookie via autosave), but yeah, there’s definitely work to be done.
I do find P2’s notifications to be a buggy, sometimes. They sometimes show the message in duplicate or worse, and P2 often gets tripped up and thinks you are logged out (look in P2’s code for “whoops_maybe_offline”). Overall a new approach could be very helpful.
I have this problem regularly since moving to separate work & home laptops (1-4x/month). The frequency comes from my own tendency to put a machine to sleep and come back the next weekend as if I never left it. And yes, I believe that code can & should play a role in fixing my own scheduling issues.
I’ve never seen those problems with P2, and mainly referenced it as an example UI. Given the checks Nacin notes this should probably be just a UX & not a functionality change.
Hey Daniel,
Thanks for reminding me about this post. I had worked on some code that would check for the logged in cookie during autosave and take some action if it’s not found (alert message, disable buttons, etc) but I can’t find it.
There are a few hurdles that we’ve experienced first hand. The result of our internal discussions has been:
– Users don’t read. Any messaging should be very short, like “Your changes will not be saved. You should copy your changes for safety. You must log in again.”
– Users don’t read. An alert box won’t work for a lot of people, they’ll just click “OK” and continue trying to save the post.
– I would put an enormous red box above the Post Title box, so that it takes up ~30% of the top of the post screen with the message.
– Disabling the Save Draft / Update buttons is a great idea.
– Polling for the cookie & displaying the alert & disabling buttons works the majority of the time, but there will be edge cases where the user is in the post for less time than the polling duration and loses a cookie. Something to bear in mind, but probably doesn’t need to be addressed in “round 1”.
– One way to solve the “clicked save before the script polled & disabled saving” problem is to override the redirect to the login page so that the user is redirected back to the edit post page, with their edits intact, and the warning message shown. This way their work isn’t lost, and the loss of authentication shouldn’t be a security hole since they still can’t save anything, they’re just quarantined to the edit post page and unable to save until they log in again.
I think basically what should happen is that, if it detects you’re logged out, you get a lightbox-esque interface that tells you: you’re logged out, and you’ll need to log back in to continue editing the post. It directs them to a new window with the login, they login, and they’re sent back to the post.
Possibly it wouldn’t even direct them to a new window, but instead all of this would happen in the same window and the draft would be saved in some pristine state (with a notice that says, “don’t worry, everything will be saved behind the scenes”).
P2’s UI is nice because it doesn’t interrupt your typing, although I would guess if an author had to make the choice between losing all their work upon save vs having their typing interrupting, they’d choose the latter. 🙂
I like the idea of saving behind the scenes and having the login in a lightbox. It would basically autosave? Or something else?
I think we’d want to save the data outside the context of the original post, maybe as hidden custom post type. Let me think this through a bit more.
Been talking to Corey Gilmore about this as well, after talking with him and some reading, I am leaning towards using localStorage.
Pros: it’s more secure than allowing insecure data to get posted back to your server, it could easily be integrated into the “Save Draft” or “Publish” buttons, you can react to the click event instead of polling
Cons: Doesn’t work in older browsers http://caniuse.com/#cats=HTML5&statuses=rec,pr,cr,wd&agents=All (IE7, Safari 3.x, Opera Mini, etc); I am inexperienced enough with localStorage that I don’t know what kind of security issues there are to be concerned with; ??? can’t think of any other cons.
I’ll try and get a proof-of-concept together on Github after August 1.
Just a heads up, https://github.com/Penske-Media-Corp/pmc-post-savior
Right now, it polls every 15 seconds and presents a modal pop-up when you get logged out. You can log back in from the modal window.
I skipped the whole “save the post data” thing in lieu of a better notification system.