The WordPress teams have been incredibly busy with fresh updates this week about the state of tickets and the advancements of WordPress 3.6. Some highlights recently have been around auto-saving, post locking, and revisions.
For example, some of the things that you will start hearing is about this new “heartbeat” API that’s being developed:
“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.
The commit is being done by @azaozz and is expected by the end of the week.
In addition, a big deal for me as an editor has been around the ability to “post lock” a post. Some of the questions answered in the recent chats have been very positive.
For those new to this conversation here’s the overview of what’s being decided:
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”.
A consensus was reached, for starters where they would display a simple lock or padlock icon (it’ll be interesting to see how this is designed) next to locked posts within the post list screen. This will then leave a “Request Lock” button for the post edit screens and when the post is locked a function to hid the “Quick Edit” link will occur to disable batch edit for the post. Unlocking will be via entering the post edit screen and clicking a button to request.
In addition, a much-talked about update regarding auto-saving has been discussed for 3.6 and is expected to appear in all it’s glory, including the possibility of autosaving to the browsers local storage:
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.
With this local editing feature a lot of publishers are going to be extremely happy. I know I will! Finally, a list of bugs, enhancements, and out-of-scope features for revisions can be found here.
There’s lots of work being done and this is just a bit of it. Stay plugged in and we’ll have more to share soon! Or head over to the Community Make boards and join in the convo!