WordPress 3.6 — What To Look Forward To
It has been almost three months since the release of WordPress 3.5 “Elvin” which brought many new features to the table, such as a revamped Media Manager and the elimination of Links Manager. That said, the roadmap for the release of version 3.6 has already been prepared, and in this article, we shall take a look at the new features and ideas that WP 3.6 is expected to bring to fruition.
WordPress 3.6 has been scheduled for release in April this year, though the Beta will most likely be out in the second week of March itself. Mark Jaquith is leading the development for the 3.6 cycle, along with Aaron D. Campbell.
And… what exactly is gonna be new in this release? I’m glad you asked!
Post Formats UI Features
Post formats have been with us since WordPress 3.1, though the user interface for post formats has not been the most usable and intuitive, to say the least. If you have felt the same, WP 3.6 will surely make you happy.
According to Helen Hou-Sandi (project lead for the post formats UI update in WP 3.6), the post formats UI will be revised to help users get a better understanding of each format. Basically, the aim is to standardize the usage of post formats across themes: most likely, developers will no longer need to form a set of assumptions and use custom fields when dealing with post formats in WordPress. As of now, the list of inspirational sources includes CF Post Formats, WP.com and of course Tumblr.
The Alpha release of WP 3.6 that I have been test driving has made changes to the Add New Post page itself: once you open the page, right above post title, you will notice multiple tabs, which will allow you to select the required post format (plus, each post format will have its own settings, such as “Source” for Quote post format and “Gallery Shortcode” for galleries). For instance, this is how the Article Editor looks like when adding a new quote:
And the site front-end, showing Status and Video post formats in action:
Post formats has always been a great feature in WordPress, but sadly, the implementation has always left a bitter feeling. Hopefully, WordPress 3.6 will finally put the usability woes to rest and we will be able to see better and more uniform implementations of this feature.
Post revisions are an excellent way to keep track of changes made to your posts, and if needed, go back to an older version of the same post. WordPress 3.6 intends to further fine-tune this feature.
The project lead-person for post revisions in WP 3.6 is Peter Westwood. The current list of suggested changes to this feature include author attribution and comparison, as well as a better user interface that will help end users get a quick visual overview of the changes made to a particular post. Obviously, a revamped visual interface for the post revisions can help users easily get an understanding of the changes made to the post.
Autosave and Post Locking
Autosave is one of the least appreciated, though most important, features in any writing tool: after all, no one likes losing their hard work due to a browser crash, right?
Sadly, many WP users have had issues trusting WP’s autosave capabilities — to the extent that some people generally write their content elsewhere, possibly in HTML editors or word processors, and then paste the same in WordPress, instead of using WP’s editor directly.
To quote Mark Jaquith,
I want, as a major 3.6 bullet point, that 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, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable.
A lot is being done to enhance the autosave mechanism in WordPress:
- WP Heartbeat API: An API that will send requests to the server every 15 seconds, and trigger events on receiving the response.
- Post Locking: A feature that can help prevent loss of data due to simultaneous editing of a post.
- Autosave (to local storage): This can prevent loss of data from the interval between two saved (to database) post revisions.
- Login Expiry: This will prevent loss of data due to cookie expiration.
Oh yes, just like each new WP release, version 3.6 too will have its own theme, named after, ummm…. the current year!
However, Twenty Thirteen will not resemble its predecessors (namely, Twenty Eleven and Twenty Twelve) in terms of appearance. Instead, the new theme is meant specifically for personal blogging sites. This change in design seems to make sense — WP 3.6 is focusing on better blogging, and improvements in the post formats section. Naturally, the theme should complement the changes, and thus, Twenty Thirteen focuses more on blogging and comes with support for post formats; in fact, the homepage works without a main sidebar, much like a tumblog.
Some Other Changes
I shall now take a look at those features which are currently under discussion, though the Alpha release that I have been using does not yet have them. Probably, when the Beta version comes out in mid-March, we may get some to see these changes in action (or, sadly, they may not make it in either the Beta or the final version due to schedule constraints). Nonetheless, the trac discussions have been buzzing, so let us take a quick look:
WordPress 3.6 is expected to come with many new changes and improvements made to the editorial workflow, especially for multi-author blogs. Simply put, you can expect some changes in the custom post statuses section, possibly with a standardized post status API.
Thus, if you are running a magazine site, you can expect to easily add post statuses such as Pitch, In Progress, Expired, and so on (as of now, there is a plugin for that, created by Daniel Bachhuber, who is also involved in the editorial workflow project team for WP 3.6).
However, a better and more likely option is that you may not notice much in the Dashboard itself, because majority of the editorial workflow improvements will be made in the API, thereby making life easier for plugin developers who wish to extend the editorial workflow.
Distraction-free editor came into existence with the release of WordPress 3.2 It has, so far, garnered all types of feedback, both negative and positive. As someone who often uses Habari simply because the CMS has a nimble and clean interface, I find the DFE to be a great feature in WordPress.
However, the distraction-free editor has received its own share of criticism, such as the fact that it does not have all the required tools to help you edit a post (for instance, in visual mode, you do not have the ability to transform normal text into headings using the toolbar), there is excessive reliance on keyboard shortcuts, and so on.
While there aren’t many discussions on the trac about changes to the DFE, some of the mentioned issues and suggested changes include the fact that the transition to DFE is slow, it does not support certain tools essential for writing and it is not so easy to discover — as a result, there is a small possibility that the DFE may receive minor facelifts.
While menus have been a part of WordPress for quite some time now, version 3.6 is likely to come with some UI improvements.
Basically, the focus is to further clarify the difference between adding items to a menu and adding a menu itself to your site or theme. Some suggested changes include the addition of accordion styling to menu items, better RTL languages support and improved cross-browser compatibility.
Primarily, the usage of menus at WP.com is being considered as a yardstick. The pie-chart shown alongside displays a broad division of menu usage trends at WP.com (as shared in the WordPress 3.6 Cycle discussions).
A hookable meta box showcasing certain common links, such as Login and Homepage, is also under discussion. Dave Martin is leading the menu development section, and you can catch a glimpse of the suggested changes here.
Under the Hood
Now, coming to the Code Maintenance, Bug Gardening and Architecture section. Apart from caching and performance tweaks, there will be many other updates to the WP core, such as:
- WordPress 3.6 is heading towards PDO extension for supporting database connections. This makes sense because mysql_* functions are deprecated in PHP. As a developer, you will need to make use of the native wpdb class to interact with the database so as to remain compatible with future PHP versions.
- Beyond that, in wp_terms, the UNIQUE constraint will be removed from the slug. This is being dubbed as preparation for future taxonomy architecture changes.
- In terms of caching, many tweaks and changes are being proposed. For example, get_term_by() calls will not be cached.
- There is also a possibility of using wp_cache_get_multi() — though this has not been accorded top priority.
Curious about WordPress 3.6? You can stay updated with the latest changes by following the Make WordPress Core.
What are your expectations from WP 3.6? Which features would you like to see added or removed? Share your thoughts with us in the comments below!
- Some screenshots obtained from the Make WordPress Core discussions.