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.