Autosave and Post Locking
Components and design
As Mark pointed out earlier, this task includes several different components:
“WP Heartbeat” API, #23216. This will do polling or long-polling so the server is able to send data and notifications to the browser. The primary use will be for setting, monitoring or taking over a post lock. Additionally it will be used to send autosave data to the server. It looks like we won’t need long-polling for now as post locks are not that time sensitive. A “standard” polling every 15 seconds would be sufficient.
Post locking. How exactly to lock a post and how a user can take over the lock? Best would be to prevent user B from being able to edit the post while user A is still writing or editing. Some ideas discussed at the IRC meetup yesterday are to overlay a transparent div over the editor and/or set the form fields to read-only. There will be a button for user B to take over the lock, clicking it will prompt user A to save the post and close the browser tab. While user B is waiting to take over, we could show a non-editable “preview” of the content (even inside the editor) updated with every “heartbeat”.
In addition we would show whether a post is being edited on the Posts screen (list table) , perhaps with the same type of button to request taking over. Other ideas welcome.
Autosave to the browser’s local storage, #23220. Keep several revisions of the content on the user’s hard drive, saving every 10 seconds and “flushing” to the server every 2 minutes (same as currently). After saving to the server (including saving a draft or publishing), empty the local storage and start again. So at the end of creating or editing a post, the local storage will be empty.
This will require “plugging into” the revisions API for restoring revisions from the local storage and some UI for letting the user recover the last revision from local storage when it exists.
Log-in expiration warnings. Update the current functionality to use the new heartbeat API and improve the UX and UI. We can detect cookies expiration earlier and show a warning that would open an iframe so the user can log in again. After that interim log-in, we will need to update all nonces.
Office hours
The first feature team meeting in IRC will be next Tuesday, 22 January at 1pm PST / 21:00 UTC. Please join us if you’re interested in participating in the development of any of the above components.
Alex Mills (Viper007Bond) 1:02 am on January 19, 2013 Permalink
Here’s some previous work on the expiration warnings: http://wordpress.org/extend/plugins/pmc-post-savior/
Jon Brown 1:38 am on January 19, 2013 Permalink
Re Post Locking: can we keep in mind the future possibility of real-time collaborative editing or is that just way to far out of scope to even plan for?
+1 to the 2nd user to enter the editor to be displayed the post in a “locked” view with a button to “request control” or “take control”
adamsilverstein 9:22 pm on January 19, 2013 Permalink
real-time collaborative editing sounds great for a future release.
Mike Schinkel 1:45 am on January 19, 2013 Permalink
This is exciting stuff. Will the autosave have ways to contribute custom content that might be stored in custom metabox fields, attachments, and other relevant items ? Maybe that already exists but if so I wasn’t aware of it.
Peter Westwood 11:22 am on January 21, 2013 Permalink
@azaozz do you think you could you take a look at #7392 as part of the work on Autosave improvements?
Ryan McCue 12:00 pm on January 21, 2013 Permalink
By the way, for anyone looking for related tickets, I’m trying to keep them tagged under autosave-redo: http://core.trac.wordpress.org/query?keywords=~autosave-redo
Andrew Nacin 12:16 pm on January 21, 2013 Permalink
Looking at open tickets in the Autosave component should be sufficient, optionally limiting that to 3.6-milestoned tickets (which shows some need a milestone).