Roadmap, Features, to Keep WordPress Awesome

WordPress has been at the forefront of publishing disruption by bringing smart, easy, capable, industrial-strength publishing to anyone and everyone. That’s why we love it.

But if WordPress is to keep its mantle as the “people’s champion” then it has to respond as publishing and publishers’ needs evolve and the issue with the upcoming 4.0 major release (like many before it) is that there’s precious few signs of what might lie ahead.

Where is the roadmap? What features or capabilities could future WordPress releases include? How will WordPress maintain its position as the world’s favourite online publishing tool?

Rae’s post yesterday on the underwhelming nature of 4.0 caused a bit of a stir yesterday.

Pippin Williamson’s thoughtful response (Refinement: the greatly unappreciated aspect of project releases) is the perfect illustration of a viewpoint depending on whether you sit on the developer side or the user side of the WordPress fence (or painfully straddle it).

If, like me, you view WordPress as a tool and not as a piece of software then Pippin is absolutely right: we don’t appreciate refinement, in fact, we appreciate very little that happens “under the hood” until it manifests itself as something we can see and “touch”.

Unfair? Perhaps. A valid (but surely not new?) developer’s lament? Certainly. A rod to beat users over the head with? Nope.

Users will never care about refinement because it doesn’t directly affect them and that’s why when the owner of a WordPress website manually upgrades their site to 4.0, they might just be a little underwhelmed by what’s new.

WordPress Is A Tool For An Industry In Flux

Whilst WordPress as an application framework has got some traction, it clearly owes its enormous popularity to its use as a publishing tool.

We can talk about the shallow learning curve, the ready support, the extensibility, the ease of set-up but for many of us, it’s the egalitarian nature of WordPress that gets our juices flowing: anyone can publish a site using the same platform as the New Yorker.

Yet we also know that publishing is an industry in constant flux, subject to often tumultuous change and engaged in a level of experimentation possibly not seen for centuries.

So, openly thinking about and robustly discussing how WordPress is situated to remain the publishing “disruptor-in-chief” and how it can continue to make industrial-strength publishing freely available to anyone who wants it is appropriate, healthy and necessary.

Roadmaps Need To Be Visionary

One of the most surprising, perhaps even alarming, aspects of WordPress is its roadmap. How is the future of a publishing tool used by tens of millions of websites decided?

After the 2.1 release, we decided to adopt a regular release schedule every 3-4 months with the features primarily driven by ideas voted on by our users.

That’s an admirable approach (software by the people for the people) and a genuine reflection of the ethos of open source. But we are talking about a major, major tool operating in an industry that’s undergoing monumental change due, in no small part, to tools like WordPress.

The roadmap needs vision. It needs to be aligned with what is happening in its predominant market (publishing) and it needs industry expertise. Ultimately, the roadmap needs to be able to look much further ahead than one or two releases, to recognize, anticipate and predict what’s happening in online publishing and to make plans for WordPress that will keep it ahead of the curve.

By all means vote on ideas but those ideas must fit within the bigger picture; they must contribute to moving WordPress down that roadmap. They cannot be the roadmap itself.

Now, maybe there is some overarching document or a working group that manages and articulates the long term strategy and direction for WordPress but if there is, then it isn’t obvious.

And, if it isn’t there then I put my hand up to volunteer in whatever capacity I can because I genuinely think that equitable access to publishing tools is up there with net neutrality and WordPress is that access.

5 Features The Roadmap Could Contain

So, what could WordPress be considering? What will help it continue to evolve as the premier publishing platform?

I have 5 major features on my wishlist covering abstraction of markup, further separation of data from design, improved publishing processes and a new content model. Most of these are fundamental changes and, ironically, fall into Pippin Williamson’s unappreciated refinement category.

It may also be that a change such as  the new content model, impacts profoundly on backwards compatibility. I know that this goes against a central tenet of the WordPress upgrade philosophy but there must come a point where some aspect of the current architecture is restricting further development to such an extent that it has to be changed.

1. Improved Collaborative Editing and Workflow

WordPress may no longer be just a blogging tool but its workflow is certainly still that of a single user install.

Yes, there are plugins that will extend the editing and workflow but a modern content management system should, out-of-the-box allow appropriately authorised users to:

1. Create new and manage existing post statuses
2. Create new and manage existing workflows, including assigning specific workflows to specific content types
3. Use an editorial calendar to plan and manage content publishing (at WPMU DEV, we have found the Editorial Calendar to be a massively useful productivity tool)
4. Create drafts of existing content without impacting on the current published version

All these can be achieved through plugins but, as we all know, every plugin increases management overheads, potential conflicts and risk. Essential functionality should be included in the core.

2. Semantic Markup As Default, Complete Abstraction Of Markup

Semantic Markup was introduced as a theme feature in the 3.6 release and, if activated, results in WordPress outputting semantically correct HTML5 for such snippets as the search form, captions and comments.

Clearly, this is for backwards compatibility but at some point WordPress is going to have to bite the bullet and turn this around completely and make semantic HTML5 the default and legacy support the theme feature.

The sooner this is done the better as delaying simply makes the problem and the impact of change bigger.

Better still would be the complete abstraction of any markup currently stored in the core to a location that can either be easily edited or overridden, providing the ultimate in flexibility.

3. Using A Templating Language For Themes

This is not a new idea but given the continual development of PHP as serious development language, rather than the templating language it was originally conceived to be, and the arrival of far better alternatives such as Twig and Liquid, it’s an idea with considerable merit.

The consequence of using a templating language is the complete separation of data from design, an approach that provides 4 major benefits:

i. Cleaner, easier to maintain template code

Templating languages are designed for one purpose, formatting the data provided to it by the application, and are far more concise, and thus easier to create and manage, than their PHP counterparts.

ii. Focus on (and master) one part of the process

WordPress themes are a hash of formatting pre-fetched data (WP_Query) and fetching and formatting new data as required either in the template or by processing shortcodes or via widgets.

In a typical templating scenario, these responsibilities are split between the underlying application (e.g. the content management system) which focuses just on collating all the pertinent data, and the template which uses that data to generate the output.

This split of responsibility may also provide new caching opportunities with either full or partial caching being possible at the data level rather than the HTML output level. Keep your cache and change your theme.

iii. Easier, independent theme development

Independence manifests itself in 2 ways. Firstly, with WordPress simply focussed on collating the data for the template, any compatible templating language can be used. Twig, Liquid, Smarty or roll your own, it’s your choice.

With design separated from data the development of the template can be done quite independently from WordPress. All that’s needed is to generate and supply test data to theme in the correct format.

iv. Targeted extensions

If you think about the various plugins that you have activated in your WordPress install they likely cover the full range from extending the admin interface, adding new features and extensions to the front-end.

Templating languages come with their own methods for extending their functionality meaning that even functionality can be separated between data collation and design delivery.

4. A More Robust And Flexible Content Model

As we all know, the WordPress content model is still essentially that of a blogging tool. Of course, this can be extended via custom content types and custom fields and there are a number of excellent plugins such as Pods, Types and ACF that provide excellent tools for managing customized models.

However, it was whilst reading a recent article on implementing long-form content on the Craft CMS that it struck me how relatively inflexible the WordPress content model is and no matter how good the various plugins are, site development can often fall into the realm of bending WordPress to our will, working against it, rather than with it.

The content model needs an overhaul.

It needs to be free of any assumptions and allow us to construct and create the content types that are pertinent for the site. Being able to extend an existing type would be good but it must not be wedded to any particular model.

Building content types needs to be part of the core with the flexibility to have free-form documents, the ability to decided at the time of creation how a particular piece of content is constructed.

As the requirements of publishers of all sizes become more sophisticated, WordPress is going to need a level of flexibility that the current data model will struggle to provide.

5. Multi-Platform Support

Today (17th July) is the 4th anniversary of the release of WordPress 3.0. Those 4 years have seen continued upheaval in publishing and the continued rise of the use of tablets and mobiles to access content.

According to the most recent figures from Pew Reasearch, in the US, 55% of adults own a smartphone and 42% own a tablet computer. Impressive numbers that presumably will continue to rise.

Making WordPress fully “platform-aware” could dramatically aid a site owner’s ability to easily tailor the experience according to the device by building into the core:

• Specifying alternative menus by platform
• Switching themes based on the platform
• Assigning plugins to a platform (e.g. only activate these plugins when servicing a request from a mobile)
• Restricting content model elements to a particular platform and allowing overrides (e.g. you create a new element called Mobile Title and set up a rule that it replaces Title on mobiles).

It’s About Keeping WordPress Awesome

WordPress represents an extraordinary effort and without doubt the number of people-hours spent on the project is, perhaps, without equal. That effort absolutely cannot be questioned.

What can, and should always, be questioned is where that effort is directed and asking where is this tool that we all work with, rely on and get excited about, is heading.

That’s not “old” or “boring”, or suggesting that WordPress is no good. On the contrary, it’s healthy and essential, it says this tool is awesome: how do we keep it that way?

What are your challenges, and the industry challenges in general, that you would like to see WordPress tackling? What major features or functionality would you like to see in the roadmap? 

Tags:

• future
• roadmap