WordPress Core, the next battles

What are the next battles we should take to improve WordPress technology and workflow? What should we do next?

I've been part of the WordPress community for more than a year now, which is really short in WordPress time, but I truly love this community and I hope to contribute for several more years. This year has been amazing in terms of Development and Workflow evolutions in the WordPress community, partly pushed by Gutenberg. Let's continue modernizing WordPress!

In this very subjective post, I'm going to list some of the battles worth considering for the future of WordPress. No battle is easy, but remember:

we're on a marathon not a sprint and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day.

Git and GitHub

Trac served WordPress very well, it centralizes all discussions and patches in one consistent place, but is it the right tool for a large Open Source project in 2018? Is it time to move to something else?

A new generation of developers works exclusively on Git and GitHub. Casual contributors won't invest time to learn a tool not used in any other place (I'm probably exaggerating a bit here) just to submit a small PR/patch. And often these casual developers evolve to become regular ones.

With Trac, the barrier for the first contribution is huge and projects like the REST API already showed that merging these feature projects into Core (which also means moving from GitHub based workflow into Trac) leads to a big decrease in terms of contributors and contributions.

Yes, this is not easy as Trac holds a big history of conversations and patches, we probably have several processes and scripts based on Trac, but it's definitely worth a battle, WordPress will benefit from the same dynamic/contributions around Gutenberg for all its components.

Deprecation strategy

This is going to be controversial. When it comes to backward compatibility, WordPress is unique. It's the only software where you can skip 9 major versions, update to the last version and your website still works (mostly). While this is huge in term of stability and confidence in the future, this philosophy of "always maintaining backward compatibility" has limits.

First, every version of WordPress comes with some "small" backward compatibility breakage but it's really hard to know where to draw the line. It's not clear which things we can never break in releases and what is an "acceptable" backward compatibility breakage.

Also, this obsession to always maintain backward compatibility is not serving the code base of WordPress. Each new version adds new APIs, duplicating and enhancing some existing APIs but not removing any old API (with some "acceptable" exceptions). This affects badly the performance and the size of WordPress. And gives this feeling of heaviness WordPress suffers from.

Can't we have the best of both worlds? A way to upgrade from old versions safely and a way for developers to deprecate and remove features, APIs from WordPress?

I'm certainly not the first one to propose something like this but I'm curious to know why can't we achieve this "coherent" deprecation strategy:

  • Plugins should explicitly declare WordPress versions support. There's already the "tested up until" field for Plugins. It should be blocking which means if you have a plugin that does not have a compatible version with the latest WordPress release, you can't upgrade unless you disable this plugin.
  • Upgrading to the latest version also updates the plugin that needs to be updated to work with this last version.
  • Transition periods where the old API and the new ones are available at the same time.
  • Tools and APIs to allow developers to declare "deprecated APIs" to warn plugin authors about the need to update their plugins.
  • Can we also consider "SemVer" for WordPress and Plugins?

Granted that this will be a fundamental change in WordPress's philosophy, but I think a change like that is necessary for the future of WordPress.

PHP version of course

I believe the work to achieve this has already started but yes we need to update the minimal PHP version required to run WordPress. This will not only improve the developer experience in WordPress Core but improve the security and performance of all WordPress websites.

I'm not heavily aware of the current efforts (as I'm not very engaged their as well). I know a field to require a minimal PHP version has been added to plugins, but we can do the same for WordPress releases. We can disable upgrades if we detect an incompatible PHP version.

I'm optimistic about this specific point, I believe we'll achieve this soon enough. But we should also work on the deprecating and upgrade strategy to allow us to continue doing this (updating the minimal version) in the future.

Stop arguing about Code Style and go standard

Developers in general (and WordPress ones confirming the rule) like to argue about code style and personal preferences. WordPress cares a lot about tabs and spaces around parenthesis and semi-colons… Why? Can't we stop caring and arguing about this, can we just follow a standard and stop talking about this? Let's focus on the code itself, let's add `prettier` to auto-format our code. We'd be consistent across our code and consistent with the outside community.

Languages like Rust, or Go successfully unified the code style using built-in tools and prettier is trying to achieve the same thing for JavaScript and PHP. Hundreds of open source projects are already using it.

WordPress code is not special. If prettier is producing readable and consistent code for millions of developers, it can do so for WordPress developers as well.

Yes, this means huge commits to apply this the first time which may affect the history, but we already did this before using phpcs. Worth a battle!

GraphQL, why not?

Among developers, WordPress is often considered as "oldish technology". What if we change that? What if WordPress becomes this hype technology everyone talks about? For this to happen, the WordPress codebase need to be modernized. In addition to the PHP upgrade,  the gradual switch to an SPA, WordPress can improve its "headless" capabilities by adopting `GraphQL`.

WordPress has been slow to adopt the REST API and it's not really a success as its usage has not seen this big increase we hoped for when merging into Core. REST APIs based applications can suffer from performance issues, especially if you want to query a lot of "related" data. How can we fix those?

In the last years, the web saw the rise of GraphQL. A Graph-based query language to provide data through an HTTP server. There are several advantages of this approach and developers in the WordPress community understood this. Plugins like WPGraphQL already do a great work exposing WordPress data though GraphQL with the extensibility expected from any WordPress feature. Can't we merge this (or an alternative) into Core to make it available to everyone?

As we move towards client-side UIs in WP-Admin aswell, this will help us a lot bringing consistency, performance and a good DevX (Declarative components) to our code-base.

Development Workflow

Another controversial point. WordPress has a relatively small group of Core commiters allowed to commit patches proposed by anyone. This gives a huge responsibility to this commiters when reviewing patches. This is good, it ensures that only high-quality (hopefully :P) patches get merged. But this has a perverse side-effect: In order to merge your patch, it has to be perfect which means often months of work for small features or bug fixes. I love iterations, I believe we can achieve way more by being a bit more flexible.

  • Let's merge unpolished features hidden behind feature flags.
  • Let's be less perfectionist. Better is the enemy of good.
  • Let's merge unpolished smaller patches. Reviewing several small patches is way more efficient and faster than reviewing one huge patch.

I admit this philosophy can create some unpolished code from time to time but I do believe we have the same problem with the current stricter approach without the benefits of faster iterations.


WordPress has a lot of documentation but How hard it is to find what you're looking for? The fact that this documentation is often built in silos (featured plugins or separate teams) and then merged into WordPress.org leads to this situation. If you navigate through the documentation, there are at least three different "styles" of documentation pages you can go through.

I know the documentation team is spending a lot of time trying to improve the experience but often, it's hard to step back and think about the whole picture. I believe the only way to fix the documentation is to rethink it entirely from scratch. Some ideas include:

There are several types of documentation but all of them should merge into a unique experience:

  • Generated documentation (PHPDoc, JSDoc)
  • Developer documentation (often written in markdown)
  • End User documentation

Should we use WordPress to document WordPress? I don't think so, can't we build a WP documentation tool with the following features:

  • Support markdown.
  • Documentation as code (live with the code).
  • Support i18n.
  • Coherent themable stylesheets.
  • Usable separately by plugins and featured-plugins (which makes merging into Core consistent).

NPM Like plugins/themes registry (CLI based)

Plugins and Themes proposals, reviewals and updates are handled using a centralized SVN repository and a lot of processes (manual or semi-automated).

Themes submissions can take months, plugin submissions weeks. I believe this aspect of the WordPress community can be made more efficient. If we have to rethink the way the repository work today, how can we make it better. What can we automate? What should stay manual? Is the SVN repository a good solution to host plugins and themes in 2017?

Nowadays, most plugins and themes have separate Git repositories and use the SVN repository only to update and tag new versions, this makes the SVN repository useless. What if we build an NPM-like CLI with commands like.

  • wpr check To check the validity of the theme/plugin (code styles, tide check…)
  • wpr login To login (required to submit plugin/themes)
  • wpr publish To submit your plugin/theme to the repository

I would love to use such a tool ❤️


This is not an exhaustive list and it's very subjective and there are probably some existing projects addressing some of these issues. I'm just trying to think about the whole picture. And you, what battle do you think we should take?

A special thanks to all WordPress contributors (Documentation, A11y, Plugins, Themes, i18n, Development…)  I'm very grateful to be part of this community, I've learned so much during this year among you all.

Thanks Grzegorz Ziółkowski for the feedback

This post is brought to you by the new Gutenberg Editor 

7 responses to “WordPress Core, the next battles”

  1. I agree with all your ideas.

    I’m sick of using trac, see that for smaller patches, it could take years, and no body review your contribution (sometimes just because it’s not the top priority), so contributing to WordPress is a real challenge and I’m in lack of motivating because of that.

    It’s also painful to have to keep your code compatible with PHP 5.2, we can’t use new array notation, namespaces, autoloading, closures and so on. There is a working group created to handle this issue with old PHP compat. They are planning to write a message to websites/hosts using old PHP version if I’m not wrong (just check WordPress core blog).

    It’s also frustrating to keep this backward compatibility philosophy which avoid us to modernize the current codebase. I guess if we continue in this path, WordPress will be out of date, slow and hard to maintain.

    By the way, in my concern, I also want to see WordPress using Composer in order to use autoloading for example and allow us to manage dependencies properly. It’s not really easy today to have a good development workflow for web agencies working with WordPress.

    Thanks for your post Riad, it was really interesting, it’s nice to hear your fresh experience about WordPress 🙂

  2. WordPress cares a lot about tabs and spaces around parenthesis and semi-columns… Why? Can’t we stop caring and arguing about this, can we just follow a standard and stop talking about this?

    It also doesn’t look like this rule will be ever supported by Prettoer. See my related comment and other responses on GitHub: https://github.com/prettier/prettier/issues/1303#issuecomment-353577704.

    Automattic solved that issue for Calypso by forking Prettier and adjusting support for spaces to make them play nicely with WordPress coding styles. See https://github.com/Automattic/calypso-prettier.

    However I would prefer to follow your advice and updated coding styles to make them compatible with Prettier. I guess it would be quite a good idea to assume that spaces can be omitted whenever code uses ES6+.

  3. Hey, Riad! 🙌

    This article is so on point with what I have long thought and discussed in the community. Last year on our WordPress meetup I presented an idea of how we can transform WordPress to be built at GitHub and have an NPM like package + dependency management model.

    This is 💯 of what we need to improve the lives of WordPress developers. If you ever find yourself leading an effort on any of these ideas, count me in, I’d be there to help contribute and bring awareness across the community.

    P.S. Currently fighting my way through support both ESLint + Prettier for WordPress.

    • Hey Ahmed, Glad to see that we’re on the same page.

      > If you ever find yourself leading an effort on any of these ideas, count me in

      Awesome! I don’t know if I have enough WP experience and legitimacy to lead big changes like that but yeah, I’ll try to advocate for these changes as much as I can. One of the goals of this post is to start (or revive) the discussion about those among committers and the whole community.

      Also, I’d love to see the blockers raised to be able to think about how to overcome those.

      Look forward seeing what we can achieve 🙂

  4. @Riad, I like your practical and pragmatic outlook. Absolutely we need to get in sync with official PHP supported versions. On the issue of git, I think its coming, though it will likely be hosted on WP.org and not GitHub.

  5. Hi Riad thanks for your article. Couldn’t agree more when you say that finding docs for gutenberg is hard. I have searched for tutorial on gutenberg core development .
    I mean how gutenberg works under the hood but all I have found is tutorial on making blocks.
    Do you know when I can found docs about that ?