Agenda for today’s autosave and post locking team meeting at 21:00 UTC:
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.
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.
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”
real-time collaborative editing sounds great for a future release.
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.
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
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).
A bunch of unused images were removed from core in changeset 21498. Several of them were background gradients that were replaced with CSS 3 gradients. The rest have been unused in core for few releases.
However there are some plugins that use a few of these images and would need updating. Best thing to do would be to copy the images locally as that makes a plugin independent from core changes. If the images were gradients, best would be to use CSS 3 gradients (example).
Very nice!
Hey just out of the curiosity, is there a special reason why MS filters are not in CSS gradient, or is that because this is CSS3 only?
Example:
filter:progid:DXImageTransform.Microsoft.gradient(startColorstr=#fff, endColorstr=#000);
and maybe add
-ms-linear-gradient as well 
Thanks,
Emil
Hey Emil,
the -ms- prefix for gradients is no longer necessary for the final IE 10, see http://blogs.msdn.com/b/ie/archive/2012/06/25/unprefixed-css3-gradients-in-ie10.aspx.
MS filters are ugly, but there is a ticket for it: #19233
By the time WordPress 3.5 is released (December 5) IE10 would be out (October 26) and as Dominik said it supports the standard CSS3 gradients.
The core ticket is about adding CSS gradients support for older IE (7, 8, 9).
Thanks guys
Emil
The first cycle finished yesterday. First run patch for supporting HTML in image captions is on #18311. Includes handling of the HTML in both editors and basic UI for inserting a link in the image properties tab in the gallery.
For the second cycle: testing, refining and committing HTML support for image captions, finishing up DFW support for editors not on the write screen, other editor enhancements and code improvements for example using the native MCE dialogs for our plugins instead of thickbox.
Cycle ending on February 22.
(George Stephanis and Zach Abernathy)
1. Admin Left Nav Menu Scroll Independently ( Enhancement )
The idea is for the Main Left Nav to scroll independently of the body, and metaboxes on the right to create the most usable interface for tablet users. This will create more of an “app” effect best for navigating and using the WordPress admin without the use of an actual app. It was decided not to go this way in #19994.
2. Clean Up Touch UI for Left NavMenu / Flyouts ( Bugfixes )
While the flyout is mostly usable in it’s current state, it is not as intuitive as it needs to be for the best user experience. They are ineffective at best on the Kindle Fire’s Silk Browser, but work pretty well on the iPad. We need to examine all target devices to ensure interactivity is supported cross-device.
3. Possibly add support for dragging of meta boxes
In the desktop version of WordPress a user has the ability to move metaboxes around to customize their interface. However, touch-and-drag support is not as intuitive on a tablet. There are possible work-arounds that need to be explored. Alternately, there is the possibility of pre-determining the number of columns and not support drag-and-drop.
4. Dashboard and write screen columns (with @media)
Determining the number of columns that are present in landscape view versus portrait view. This would need to be tested on a per device basis to determine the optimum number of columns. In WP 3.3 this effect was generated via JS. We should be able to yield better performance by handling this via CSS.
5. Resolve Amazon Silk Browser ( Kindle Fire ) WYSIWYG Incompatibility
Currently, the WordPress WYSIWYG (TinyMCE) does not work in the Android Fire Silk Browser, but it does on the native Android browser. This is due to the Silk browser still not supporting the `contentEditable` attribute properly.
Now that WordPress 3.3 is in feature freeze, it’s time to have a look at some new Javascript goodies for developers:
We were using a very early version of #2 and it’s been working great, excited to integrate the full 3.3 Editor API and have it work to the full extent we and plenty of other hungry developers have waited for
Question about plupload, Does it include the option to spilt the upload in to samller chunks? So basicly does core included all the feature of the wplupload plugin https://wordpress.org/extend/plugins/wplupload/
No that’s not enabled by default but can be set by a plugin. Seems only Chrome handles splitting the file into chunks properly at the moment. It would have been nice to remove the upload size limit
When more browsers start to support this reliably we can enable it by default, probably 3.4.
Currently using the plugin and file spliting works in opera and Firefox 6+, However I am using the flash runtime not HTML5.
Great news on Editor API and `wp_localize_script()`!!!
Glad to see the full jQuery UI (also, looks like I picked the correct script names in Use Google Libraries way back, so I won’t need to make changes in there when 3.3 comes out).
I hope the TinyMCE editor will offer tables in WP by standard so that I would not need to install any plugins anymore….
No, the default TinyMCE configuration in core has not changed. Most functions related to it were combined in WP_Editor class.
Too late for jQuery 1.7?
1.7′s already in – though that’s another kettle of fish.
To all that responded to the idea for CSS cleanup in 3.3: have your say at The big CSS overhaul in 3.3, part II.
There have been two major releases of the jQuery library during this release cycle. WordPress 3.1 includes jQuery 1.4.4. WordPress 3.2 will include jQuery 1.6.1. The new jQuery is faster and better but also has some major changes. The two most important changes that all plugin and theme authors must test for are:
Max, $('input[name=submit]')
will not work. It needs to be
$('input[name="submit"]')
.attr('checked', '')
fails (that used to remove the checked=”checked” from checkboxes). More details and a list of all affected properties are on the jQuery’s blog.
Are we using 1.6.1?
From the post:
WordPress 3.1 includes jQuery 1.4.4. WordPress 3.2 will include jQuery 1.6.1.
Yep! It’s going to be jQuery 1.6.1 in 3.2
http://core.trac.wordpress.org/ticket/17311
great jQuery 1.6.1 will power the WP now….
Two queries…
Will you be using the min JS?
Your use of $ there doesn’t happen to mean you’ll be supporting that in 3.2….?
WordPress has always used the minified version, have a look
What do you mean by “supporting”? Making $ belong to jQuery in the global scope and breaking Prototype.js? Don’t think we want to break all plugins that use Prototype.
Sorry. You’re right, I didn’t actually look at the code.
And yeah, I woulda been surprised, but was just hoping.
So let’s say your plugin uses .attr(‘checked’, ”). What do you do to make sure that it works for version 3.2 and lower?
Calling all CSS “Gurus”, well everybody that is interested in CSS to voice their opinions about The big CSS overhaul in 3.3.
The Distraction Free Writing mode has been in trunk since yesterday. Would appreciate comments, suggestions, opinions, etc. Bug reports should probably go on #17136.
I’m a fan of it so far, but I haven’t had the chance to really field test it and try to break things yet. Rest assured, if a bug can be found, I’ll find it … but so far it looks amazing!
Really enjoying this Andrew, great work! I posted a few screenshots for people to check, should they not have a trunk install.
PS: I’m extra happy you’re back in full force.
Thanks! Not in full “full force” yet but nearly there
ChrisH, 
Here’s some previous work on the expiration warnings: http://wordpress.org/extend/plugins/pmc-post-savior/