What we can expect from WordPress 3.6

The most recent WordPress release, 3.5, has passed the 6 million download mark. It brought us a renewed media experience and various improvements in the dashboard. But life moves on, and the scope of the upcoming version 3.6 release has already been settled.

There’s been much debate over what to expect, especially in terms of improving our publishing workflow. Fortunately, the developers give us some hints via the discussion on trac and the Make WordPress Core blog.

Let’s take a look at what’s on the horizon, to make sure our projects are prepared and we don’t encounter any nasty surprises down the road.

Mark Jaquith, who is going to be a leading developer for 3.6 cycle, declares in his introductory post:

I’d personally like the focus of the release to be about content editing (revisions, autosave, workflow, editing modes, etc).

Aaron D. Campbell will co-lead the release and he’s also expressed his intention to focus on content editing to enhance its potential for users. So, we can expect some further improvements to those little dashboard features that make life easier.

Post formats UI

Post formats were introduced in WordPress 3.1 and presently we have a lot of beautiful themes that use them to present content in a visually appealing manner. Unfortunately, the admin UI for this feature has always had some usability issues which has meant developers tweaking it for client projects.

In 3.6 under the lead of Helen Hou-Sandi things will change. Аcording to Helen the UI itself will be revised to help users better understand a particular post format. Several sources of inspiration will be worked in, in particular CF Post Formats by Alex King, wordpress.com UI and the famous Tumblr interface.

Another aspect that will be open to consideration is “to give themes something standardised and portable when it comes to data available for display”. So we can expect that finally theme developers will have the standardized set of data for each post format instead of having to make assumptions and creating their own implementations through custom fields.

Autosave and post locking

Autosaving is an important aspect of writer’s workflow — the lack of good implementation forces a lot of people to switch to external editors instead of writing directly in the WordPress admin.

On this subject Jaquith has said:

…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…

Sounds exciting, doesn’t it? Andrew Ozz is going to lead development and focus on following the components:

• Creating a “WP Heartbeat” API: a relatively simple API that sends requests to the server every 15 seconds and triggers events on receiving data. This is a step towards the simultaneous editing direction but the initial implementation is aimed at autosave and post-locking functionality.
• Post locking: will prevent conflicts and loss of data due to possible simultaneous editing of a post. The UI and notification system will be improved.
• Autosave to the local storage: will prevent loss of user data between saving post revisions to the database.
• Login expiration warnings: will prevent loss of data due to cookie expiration. Presently you can use the PMC Post Savior plugin for that, and some of its ideas will probably now make their way into the core.

Editorial flow and revisions

With the 3.6 release a long awaited step towards the improvement of editorial workflow will be made; especially for multi-author sites and blogs. Daniel Bachhuber will lead the feature. He is one of the developers behind the famous Edit Flow plugin so we can expect some of its abilities to enter the core.

It will start with custom post statuses. According to Daniel, it’s the “crux of building any new features”. So there is a clearly stated intention to finalize the custom status API, standardize its behavior and interaction with custom post types.

Let’s hope that as of WordPress 3.6 creating states such as “idea” or “expired” will be a breeze.

If you have information or examples of how existing custom statuses are implemented you can help developers by participating in the “use case” study.

Revisions are an extremely powerful tool for content tracking in WordPress. For 3.6 they’re going to be improved with author attribution and comparison under the lead of Peter Westwood. The UI is going to have more meaning to the average (read “not a developer”) user by presenting more information about changes visually.

Menus

Menu management was introduced in version 3.0 as an integral part of the “WordPress as CMS” movement. Today we cannot imagine a theme not supporting menus. In 3.6 there will be some UI refinements lead by Dave Martin. Dave shares his ideas about how the menu management screen should look in his blog and on trac. The main issue that is going to be addressed is a clearly stated difference between adding items to a menu and adding the menu itself to a theme location. As a solution, the tabbed window approach was proposed and one can see the positive results in user testing.

Apart from that, the new hookable “common links” meta box with “home” and “Log in” as the default links will be introduced. Many users have problems figuring out how to add these links currently.

Does it mean that we will see all these changes in the core? We’ll have to wait for the release to tell. In the meantime you can follow the Make WordPress UI blog for details and to participate in discussions.

Distraction-free writing

The DFW feature was debuted in version 3.2. Since then it has received plenty of attention, both positive and negative. One of the main points of contention is the lack of formatting support. WordPress does not support markdown and at the same time the DFW editor relies heavily on keyboard shortcuts. There is no leading developer for this feature but Mark has pin-pointed the following areas for improvement:

• It’s hard to discover
• The transition is a bit jarring
• Does not support the majority of formatting needed for writing
• General improvements of it’s behavior during writing

Code maintenance and architecture

As always with a new version of WordPress, there will be some under-the-hood updates in the 3.6 release. Most of them are going to deal with caching and performance issues; which is logical as WordPress becomes more complex and resource-hungry. Apart from that there are some database related things that are going to change. I’d like to highlight two:

1. The mysql_ functions are deprecated in PHP so WordPress 3.6 starts moving towards support of PDO extension for serving database connections. For developers, it primarily means that if for any reason you’re not using the native wpdb class to operate with a database in your plugin, you’d better start right now — apart from benefiting from its robust feature list you’ll also avoid incompatibility with future PHP versions.
2. UNIQUE сonstraint will be removed for the slug in wp_terms. This small detail is to prepare for future improvements of the taxonomy API, in particular how it handles shared terms.

Other planning changes can be found on the Make WordPress Core blog.

Schedule

The WordPress 3.6 release schedule is shorter than previous versions: the cycle started in early January and the first Beta is scheduled for March 13. April 22 2013 is the planned launch date. So if you’d like to participate in this cycle visit the Core track or post you thoughts on the forum.

What are you hoping for in the next version of WordPress? Where do you see the platform heading? Let us know in the comments.

Featured image/thumbnail, future image via Shutterstock.

Anna Ladoshkina

Anna Ladoshkina is a freelance web designer and developer who likes to build pretty things with WordPress and write about it. Connect with Anna on Twitter (@foralien) or on her website, www.foralien.com.