Saturday, 30 December, 2017 UTC
Summary
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:
Git and GitHubwe'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.
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-columns… 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
GraphQL, why not?
phpcs. Worth a battle!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 Code base 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 WorkflowAnother 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.
DocumentationWordPress 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).
Plugins and Themes proposals, reviewals and updates are handled using a centralized SVN repository and a lot of processes (manual or semi-automatic).
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 checkTo check the validity of the theme/plugin (code styles, tide check…)wpr loginTo login (required to submit plugin/themes)wpr publishTo submit your plugin/theme to the repository- …
I would love to use such a tool ❤️
Conclusion
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 step back a little bit after a year of contributing and 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.
This post is brought to you by the new Gutenberg Editor