WordPress is thinking about a “plugins-first” approach that would speed up core development, but some people aren’t sure it will work.
Matt Mullenweg, who made WordPress and is the CEO of Autommatic, suggested that instead of adding new features to WordPress, the focus should be on plugins.
This new plan for the future of WordPress has already led to the removal of a new feature that was planned for the next version of WordPress.
Canonical plugins are said to be a faster way to keep making improvements to WordPress.
But some WordPress core contributors said they thought the experience of publisher users might get worse.
Canonical plugins is a way to add new features in the form of plugins. It was first talked about in 2009.
The goal of this approach is to keep the core of WordPress fast and small while also encouraging the development of experimental features in the form of plugins.
In the original proposal from 2009, it was written like this:
“Canonical plugins would be ones that are built by the community (not just one person) and meet the most common requests for functionality in the best way possible.
…There would be a strong connection between core and these plugins, which would make sure that a) the plugin code would be safe and the best possible example of coding standards and b) new versions of WordPress would be tested against these plugins before they were released to make sure they were compatible.”
This way of thinking about features and options is also called “Plugin First” to show that features will first show up as plugins.
These plugins are called “canonical” because they are made by the WordPress core development team. Non-canonical plugins, on the other hand, are made by third parties, who might limit features to get you to buy a “pro” version.
Integration of canonical plugins into the core of WordPress would be thought about once plugin technology has proven to be popular and important to most users.
This new way of thinking about WordPress would make it possible to avoid adding new features that most users might not need.
Plugin-first could be seen as in line with the Decisions, Not Options philosophy of WordPress, which tries to avoid giving users too many technical options.
By giving different features and functions to plugins, a user won’t have to figure out how to turn on or off features they need, don’t need, or don’t understand.
The design philosophy of WordPress says:
“As developers, it’s our job to make smart design decisions and avoid making our end users carry the weight of technical decisions.”
The Future of Canonical Plugins?
Matt Mullenweg wrote a post called “Canonical Plugins Revisited” in which he argued that this is how WordPress should be built in the future.
“We are reaching a point where core needs to be more editorial and say “no” to features that come in as ad hoc as they sometimes do. I hope that more Make teams use this as an opportunity to shape the future of WordPress through a plugin-first approach that gives them the luxury of faster development and release cycles (instead of three times a year), less review overhead, and a path to come into core if the plugin becomes a runaway success.
The first thing that will be lost because of this new approach is that WebP image conversion won’t be added to WordPress 6.1, which is set to come out in November 2022.
Plugin-First is Controversial
In the comments section, people talked about the change to a development process that starts with plugins.
Some developers, like core contributor Jon Brown, didn’t like the idea of switching to developing with canonical plugins.
What they said:
“The problem is still that there are too many complicated plugins that do the job of a simple option.
Plugins are not an easy-to-use alternative to changing the core settings. First, users have to find out there is a plugin, then they have to deal with yet another settings screen, updates, and maintenance of that plugin.
The commenter used the fact that commenting is currently handled by a number of large plugins as an example of a less than ideal user experience.
They said that having one canonical plugin to solve a problem is better than the way things are now, where the only good options are in third-party plugins that are too big.
But they also said that a better user experience could be had if there was a settings option in core that didn’t require a plugin.
They went on:
“Now, I do think that Canonical plugins are better than 6+ bloated plugins like what we have here, but adding a single checkbox to the settings page in core would do the same thing. Which would improve the user experience and make it easier to find plugins.”
In the end, the commenter said that the idea of “canonical plugins” seemed like a way to stop people from talking about features that should be thought about, so that the conversation never happens.
“Canonical plugins” seems like a weaponized way to derail discussions, just like “decisions not options” has been for years.
This last sentence is about how some core contributors are upset that they can’t add options for features because of the “decisions, not options” philosophy.
Some people also didn’t agree with the plugin-first method:
“The Canonical plugin sounds great, but it will add to the work that maintainers have to do.
In my opinion, it’s no go.
Instead of saying, “It’s a good place for plugins,” it would be much better to include some basic features in the core itself.
Someone else said that one problem with plugin-first is that it might not be easy to get feedback from users. If that’s the case, there might not be a good way to improve plugins in a way that meets user needs if those needs aren’t known.
They put down:
“How can we better listen to what users have to say?
If site owners don’t know enough to report problems on GitHub or Trac (and let’s be honest, no one reports plugin problems on Trac), there’s really no way to get user feedback to improve these recommended or official plugins.
WordPress development is changing so that changes can be made more quickly. Comments from core contributors show that there are still a lot of questions about how well this system will work for users.
One early sign will be what happens with the WebP feature that was supposed to be built into the core but was scrapped. Instead, it will become a plugin.