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?

A long straight highway with a WordPress logo at the end.
A visionary roadmap will help WordPress maintain its place as the pre-eminent cms.

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

HTML5 logo surrounded by HTML
Semantic HTML5 markup should be default

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

Twig logo
Templating languages offer true separation of code/data from design

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

Handdrawn diagram of the built-in WordPress content model
Modelling content is one of the most overlooked tasks in creating and effective, flexible and stable site

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

Picture showing a website on a desktop, tablet and a smartphone
Making WordPress “platform-aware” would provide real help in optimizing the visitor experience

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

Super heroes
WordPress is undoubtedly the result of extraordinary efforts

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? 

4 Responses

  • New Recruit

    My issue with the development of WordPress is that it’s controlled by a VERY small group who have a vision that is inflexible. Any ideas outside the scope of how that small group sees WordPress is summarily rejected.

    Those in charge do not use WordPress the same way many others do and therefore they don’t see the need for features requested that don’t benefit them personally. I’ve sat in numerous Core chats where features were rejected despite being wildly popular among WordPress users.

    And despite recent comments to the contrary, there is no “non-developer” representation in Core. Features are determined by who actually shows up to Core developer chats and if a user shows up asking for a feature, they’re told to find a developer.

    There needs to be a paradigm shift in how the whole upgrade process works and there needs to be representation outside the select few who are chosen to be in the “cool people’s clique”. Almost every idea coming outside of that clique is dismissed.

  • New Recruit

    The senior people in WordPress are aware of questions around direction. I can only compare with Drupal. Drupal would like to be all things to all people. Still the income of most senior developers is going to come from larger corporate or government work, and they are prepared to break backwards compatibility to make a system which should be better for everyone, but which can thrive in the enterprise market. WordPress’s success boxes it in a bit: breaking backwards compatibility, and breaking a setup which relatively low-tech users are comfortable with, is not an option. Your suggestions all seem sensible, apart from the mobile device switching (which is looking a bit last year now the division between mobile and desktop is getting blurred). In the end a CMS needs to define its market. If WordPress is ‘people’s champion’ it may not need enterprise-grade structures which many bloggers will struggle to maintain or even understand.

  • New Recruit

    Actually, I think most of these mobile suggestions are spot on. I work as a WP Developer for a large media company. I’ve watched numbers change in less than 2 years from 65% desktop visitors to 68% mobile (I don’t count tablets as mobile) visitors to our web sites for radio stations (both music and news formats) and newspapers.

    WordPress needs to stop leaving mobile detection to plugins and bring it into Core (wp_is_mobile is poorly implemented). They need to take it seriously and realize that “responsive CSS” is NOT mobile.

  • WPMU DEV Initiate

    I rather agree with the need for “Mobile” — must have that.

    I am an old WP user (started with 1.2 I believe) — I have played with Drupal, Omeka, MovableType and more. I would not favor a Content model that steepens the learning curve for folks who “set up websites” — Drupal has such a curve that I basically abandoned it long ago with a headache (as I did with Joomla and some other applications). The possibly “outdated content model” that make WP easy to use is probably one of the reasons it stays as popular as it is.

Comments are closed.