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.

  • http://www.dlageeka.pl/ Balls of Steel

    Good to see that WordPress is constantly upgrading. I’am glad that will be some UI improvements in menu creation page and in post editor :D

  • Johnson Lu

    I definitely like the changes to the writing interface. It was annoying to have to format my text by having to switch between code and visual view.

    And as designers we can all agree that standardised post formats are a step in the right direction.

  • http://twitter.com/WebDevContest Web Dev Contest

    I wonder how long until more custom post stuff type is built right into WordPress. I end up using http://themergency.com/generators/wordpress-custom-post-types/ and http://www.advancedcustomfields.com/ on every project these days. I know they don’t want to keep expanding the core code, but it’s a big part of being a proper CMS.

    • http://twitter.com/foralien Anna Ladoshkina

      As for now CPT stuff is oriented more on developer than end-user, so you can do a lot from code with them, but that means that you have to customize UI accordingly… or use plugins

  • http://twitter.com/stevengliebe Steven Gliebe

    The Post Formats UI will be very welcome. With that, I think developers will be more encouraged to use Post Formats.

    PS. Hovering over the links on this site is the cat’s meow.

    • http://twitter.com/foralien Anna Ladoshkina

      Not only UI – the standards for data handling also… that’s also very helpful for developers and friendly for their clients :)

  • jaystrab

    RE: autosave… You should never write directly in any online editor. Always write in a writing app on your computer so you can save the file on your computer. Then paste the final product into your blog post AFTER you have proofread and edited it. All too often, people write in WordPress or whatever and their text never gets proofed for grammar or spelling.
    Also, it helps to have a backup copy of all posts you’ve ever written because you shouldn’t trust just your server to save that valuable information.

    • http://twitter.com/JackNycz Jack Nycz

      Never? That’s pretty strong. I write in WP all the time, especially for shorter articles. And pasting from Word almost always requires you to “fix” some things.

    • SamuliAlajarvela

      Autosave works fine with WP, better than in Word for example. I’ve lost a blog post a few times because Word has crashed and corrupted the .doc but never have I lost more than 10mins work tops with WP.

      I write directly with WordPress, at least I can easily check that the formatting looks correct. Also, I do the proof readings before I publish, the auto correct hilighting works fine in the editor.

    • http://twitter.com/foralien Anna Ladoshkina

      It depends on one’s workflow, does not it? In some case it’s better to write in special app – in some cases it’s not the best option. But autosave could be helpful anyway.

  • weeb gilmore

    Will they EVER fix the issue of custom code being wiped out when switching between the HTML and visual editor? Ever? Many have claimed this has been addressed and/or fixed. It has not. And it’s a big reason I never recommend WP to my clients.

  • http://wparena.com/ Wordpress Arena

    Its good that they are including UI, but it would be more helpful if they include how to use it for beginners

  • http://impixon.com/ AJO

    I think wordpress 3.6 will be more than that we are expecting now.

  • http://twitter.com/foralien Anna Ladoshkina

    you are right , Stian, media management for so long time was negletted in WP, may be new media things introduced in 3.5 are just a beginning, let’s hope

  • http://twitter.com/foralien Anna Ladoshkina

    I think that’s primary because there is no way to manage relationships between items in the core (you also need a plugin for that), withouth that relationship management it’s difficult to create full-fledged multilingual site. Personally, I use network feature for that need – setup a network and internal sites for each language. But there are drawbacks, certainly.