WordPress 3.6: Autosave and Post Locking
I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.
Things this will likely involve:
- Local storage of post data while editing, in-between autosaves and manual saves.
- More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
- Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
- Probably some interaction with the team working on improving Post Revisions.
- UX work for making recovery from failure scenarios smooth, clear, and worry-free.
@aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. 
Mike Schinkel 7:43 pm on January 7, 2013 Permalink
+1!
Jon Brown 7:46 pm on January 7, 2013 Permalink
+1 – May I suggest that versioning and autosaving of metadata be included in this push. I’ve seen several people become reliant on the revisions and auto-save of the content (yay, they trust it!) and then be disappointed to discover their excerpt or content in a metabox isn’t given the same treatment.
Mark Jaquith 7:55 pm on January 7, 2013 Permalink
There’s at least one ticket that touches on that http://core.trac.wordpress.org/ticket/20299
But yeah, we need to start thinking about the fact that as more people use WP as a CMS, a lot of their important data resides outside of post_content.
Travis Northcutt 8:01 pm on January 7, 2013 Permalink
Absolutely this. We make heavy use of post meta in sites we build for people, and storing revisions would be a huge plus. Does anyone know of additional tickets that address this? (The one Mark linked to is specifically focused on the fact that previewing changes to a post updates meta (silently), which isn’t expected behavior).
Helen Hou-Sandi 8:04 pm on January 7, 2013 Permalink
#20564
Travis Northcutt 11:20 pm on January 7, 2013 Permalink
Thanks Helen. Might I suggest that it would be natural for #18179 to include an argument such that when a metabox is registered, the keys in that box are then registered to have revisions tracked.
Pippin (mordauk) 7:55 pm on January 7, 2013 Permalink
Huge +1.
goldenapples 7:58 pm on January 7, 2013 Permalink
+1, I’m very interested in helping work on these features. I’ve worked with the authors on the site I manage to find workarounds for a number of related problems and have several ideas I’d like to test out:
willnorris.com 8:36 pm on January 7, 2013 Permalink
[...] Jaquith talking about WordPress 3.6, which will be focused on the post authoring [...]
adamsilverstein 9:07 pm on January 7, 2013 Permalink
i’m interested in helping if i can
John Saddington 9:19 pm on January 7, 2013 Permalink
omg. yes.
Arnan de Gans 9:22 pm on January 7, 2013 Permalink
And on top of that… While you guys are at it, make the dashboard, the whole of it, faster. Better loading, faster rendering (?) Whatever. Often on sites that have a bunch of plugins active it get’s really sluggish.
Aaron D. Campbell 10:13 pm on January 7, 2013 Permalink
This is largely dependent on what they plugins you’re talking about do on the dashboard. Sounds like they’re likely doing something wrong if they’re slowing down the dashboard that much.
Aaron Brazell 12:04 am on January 9, 2013 Permalink
Or nuke it altogether. I don’t have numbers but I’m guessing the majority of people spend 1% of their time in the Dashboard. I find it altogether useless, although I’m sure some would disagree with me.
When I login to WP to produce content, the first thing I do is click on Add New in the posts menu. That’s a hover and a click more than I need to get into content production.
John Kleinschmidt 9:46 pm on January 7, 2013 Permalink
I have been doing a decent amount of work around offline storage recently and would love to help contribute on the JS side of things.
Md Mahmudur Rahman 10:10 pm on January 7, 2013 Permalink
Excellent.
Grant Norwood 11:59 pm on January 7, 2013 Permalink
Thanks, Mark. This is a great goal, and worthy of the urgency you’ve expressed! Since you mentioned post revisions, I’d like to recommend that we think about how to better compare post/page/CPT revisions within the rich text editor. As it is currently implemented, non-technical users have difficulty comparing large amounts of plain-text and raw HTML, and often give up immediately when using the compare feature. Developers are accustomed to the unified diff format, but we’re the only ones.
Could we take inspiration from the review/editing/comparison tools used in other popular copy-editing apps (i.e., MS Word) that would make a copywriter feel more at home when comparing content revisions?
Helen Hou-Sandi 12:11 am on January 8, 2013 Permalink
Separate feature
http://make.wordpress.org/core/2013/01/07/wordpress-3-6-revisions/
Gabriel Koen 9:18 pm on January 9, 2013 Permalink
I’d like to lend a hand with this, I can provide user insight (our dev team has been fielding issues regarding this topic for a few years from a large staff of writers) as well as do PHP and JS coding for it.
Mike Bijon 12:46 am on January 13, 2013 Permalink
Definitely loop Gabriel in on this, I’ve been using his ‘PMC Post Savior’ plugin recently and it’s been a huge help in preventing lost posts: https://github.com/Penske-Media-Corp/pmc-post-savior.
The best part about Post Savior is the UX rethink. Instead of a load of JS and localStorage it allows re-login over the top of the post interface. Really simplified the JS/localStorage fixes suggested on Daniel’s blog: http://danielbachhuber.com/2012/05/01/notify-when-logged-out/
…also worth checking out the discussion on that post too. Having the JS/storage-type fixes might be needed for full protection on mobile browsers.
Mike Bijon 12:49 am on January 13, 2013 Permalink
I’d like to help with this during this cycle too.
Since I’m time-limited to being effective on only 1-2 tickets per cycle, I be happy to help with tests and testing if time there would be valuable.