WordPress Considers Historic Development Change
WordPress is considering a plugin-first approach, which promises core development to be faster. However, some people are skeptical.
Matt Mullenweg (developer of WordPress and CEO at Automatic) suggested that WordPress stop adding new features and pivot to a plugin-first policy.
The new approach to WordPress’ future has already led to a new feature that will be removed from the next version.
Canonical plugins can be used to improve WordPress’ performance more frequently.
Some WordPress core contributors voiced concern that the user experience for publishers may be compromised
Canonical Plugins
Canonical plugins were first discussed in 2009.
This approach aims to keep WordPress core lean and encourage the development of plugins.
The original 2009 proposal described it as:
“Canonical plugins” have been developed by a community (multiple developers, not one) and address the most common functionality needs with superior execution.
It would be extreme to have a close relationship between the core and these plugins. This would ensure that a) the code of the plugins would be secure and conform to coding standards, and b) new versions of WordPress would be tested against the plugins before they were released to ensure compatibility.
This approach to options and features is sometimes called Plugin First. It emphasizes how plugins will be the first to have features.
These plugins are known as canonical because WordPress core developers developed them. Non-canonical plugins are created by third parties who might limit features to encourage purchasing a pro version.
Once the plugin technology is widespread and essential, integration of canonical plugins in the WordPress core would be considered.
This new approach to WordPress will allow WordPress to eliminate the need to add new features that most users may not use.
Plugin-first can be seen as in line with the WordPress philosophy Decisions and Not Options which aims to reduce user burden by removing layers of technical options.
A plugin can be used to offload different functions and features. Users won’t need to go through all the steps to enable or disable them.
This is the WordPress design philosophy:
“It is our authority as developers to make intelligent design decisions and not place the burden of technical decisions on our users.”
The Future of Canonical Plugins?
Matt Mullenweg wrote a post titled Canonical Plugins Rediscovered, arguing that this is how WordPress should be developed going forward.
He wrote
“We are at a point in the core where core must be more editorial and say “no” to features coming into as ad-hoc as sometimes does, and I hope that more Make teams use it as an opportunity for influence the future WordPress through a plugin first approach that allows them to have faster development and release cycles (instead three times per year), less overhead review, and a path to the core if the plugin is a huge success.”
This new approach has already caused the abandonment of WebP image conversion in WordPress 6.1. It is currently scheduled for November 2022.
Plugin First is Controversial
In the comments section, a debate erupted over the transition to a plugin’s first development process.
Some developers, like core contributor Jon Brown, expressed reservations about the proposal for switching to canonical plugin development.
They comment:
“The problem is that too many plugins are standing in for a simple option feature.
Plugins are not a user-friendly alternative to core settings. Users must first discover that there is a plugin. Then, they need to negotiate yet another screen for settings, updates, and maintenance of the plugin.
For example, the commenter suggested that multiple bloated plugins currently provide a commenting function. This would make it less user-friendly.
They pointed out that one canonical plugin is better than having bloated third-party plugins to solve the problem.
They also suggested that core could have a settings option without the need to install a plugin. This would make it easier for users.
They went on:
“Now, Canonical plugins do seem to be a better solution than 6+ bloated ones like the one here. But, a single checkbox on the settings page in the core would do this. This would improve plugins’ UX and solve some discovery problems.
The commenter suggested that canonical plugins were a way to stop discussions about features that should not be considered.
“Canonical plugins” is a weaponized tool to derail discussion the way “decisions are not options” has been for years.
This last statement refers to frustrations experienced by core contributors due to the inability to add feature options because of the “decisions, not options” philosophy.
Other people disagree with the plugin’s first approach.
“Canonical plugin sounds great, but it will increase maintenance burden for maintainers.
It’s not possible, in my opinion.
Adding basic features in the core is better than further stating – It’s an excellent place for plugins.
Another person pointed out that plugin-first might have a problem collecting user feedback. If this is the case, improving plugins to meet user needs might not be easy.
They authored:
“How can we capture user feedback better?”
Site owners should not be able to report plugin issues on Trac or GitHub. (Let’s face it, nobody says plugin issues to Trac). There is no way for users to provide feedback to help improve these official/recommended plugins. “
Canonical Plugins
WordPress development is improving to improve faster. The core contributors’ comments show that there are still many questions about how this system will work for users.
One early indicator will be what happens to the WebP feature initially intended to be integrated into the core. It will now be a plugin.
