WordPress Considers Historic Development Change
historical change is going to be with the change of Canonical Plugins. Before going into deep to this change, we must have a dive into the Canonical Plugins.
What Canonical Plugins are?
WordPress development evolves to make improvements faster. The comments from the main contributors indicate that there are many unanswered questions about how well this system will work for users.
The first indicator will be what happens to the deprecated Web P feature, which was previously intended to be integrated into the core and will now become a plug-in.
Canonical plugins would be plugins that are developed by a community (multiple developers, not just one person) and address the most popular functionality requirements with excellent execution. These plugins would be licensed under the GPL and hosted in the WordPress.org repository and developed in close conjunction with WordPress core.WordPress Considers Historic Development Change is necessary now.
A pivot to a plugin-first policy is proposed by Matt Mullenweg, creator of WordPress and CEO of Automatic.
As a result of this new approach to the future of WordPress, a new feature planned for the next version has already been scrapped.
Canonical plugins are said to provide a faster way to improve WordPress.
However, some WordPress core contributors expressed concern about publisher user experience.
Canonical Plugins
Canonical plugins were first discussed in 2009 and allow developers to develop new features through plugins.This approach encourages the development of experimental plugins while keeping WordPress’ core fast and lean.
The original 2009 proposal described it like this:
“Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution.
There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility.”
The Plugin First approach emphasizes how features will first appear in the form of plugins for features and options.
Canonical plugins are developed by the WordPress core development team, rather than non-canonical plugins created by third parties that may limit features in order to encourage the purchase of a pro version.
When plugin technology has proven itself to be popular and essential to the majority of users, canonical plugins will be considered for integration into the WordPress core itself.
A new approach to WordPress would avoid adding features that might not be needed by most users.
WordPress’ philosophy of Decisions, Not Options seeks to avoid burdening users with layers of technical options, which is consistent with plugin-first.
Users won’t have to worry about enabling and disabling features and functionalities they need, don’t need, or don’t understand if different features and functionalities are offloaded to plugins
“It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.”
Canonical Plugins the Future?
In a post titled, Canonical Plugins Revisited, Matt Mullenweg argues that this is the way WordPress should be developed in the future“We are reaching a point where core needs to be more editorial and say “no” to features coming in as ad hoc as they sometimes do, and my hope is that more Make teams use this as an opportunity to influence the future of WordPress through a plugin-first approach that gives them the luxury of faster development and release cycles (instead of three times per year), less review overhead, and path to come into core if the plugin becomes a runaway success.”
This new approach has resulted in the cancellation of the integration of WebP image conversion into WordPress 6.1, due for release in November 2022.
Plugin-First is Controversial
There was a debate in the comments section about the move to a plugin-first development process.
Jon Brown, a core contributor, expressed reservations about the proposal to switch to canonical plugins.
They commented:
“The problem remains that there are too many complicated plugins standing in for what would be a simple optional feature.
Plugins are _not_ a user-friendly option to core settings. First users have to discover there is a plugin, then they have negotiated yet another settings screen and updates and maintenance of that plugin.”
The commenter used the example of multiple bloated plugins currently serving commenting functionality as an example of a less-than-ideal user experience.
One canonical plugin would solve a problem better than bloated third-party plugins that offer desirable options.
But they also said that being able to set it in the core, without the need for a plugin, could represent a better user experience.
They continued:
“Now I think the Canonical plugins are a better situation than the 6+ bloated plugins that exist here, but it would still add a single checkbox to the settings page in core to allow this. Which would further improve the user experience and discovery issues inherent in plugins.”
Finally, a commenter expressed the idea that the concept of canonical plugins seems like a way to end discussions of features that should be considered so that the conversation never happens.
Canonical plugins” seem like a weapon to derail discussions in the same way that “decisions not options” has been for years.
This last statement is a reference to the frustration some core contributors feel at not being able to add options for features due to the “decisions, not options” philosophy.
Others also disagreed with the approach in the first place:
“The canonical plugin sounds great, but it will further increase the maintenance burden for administrators. In my opinion, it doesn’t work.
It will be much better to include some basic functions in the core itself than to go on to say – This is a good place for a plugin.
Someone else pointed out a flaw in plugin-first that collecting user feedback might not be easy. If this is the case, then there may not be a good way to improve plugins in a way that meets user needs if those needs are not known.
They wrote:
How can we better capture user feedback?
Unless the site owners are knowledgeable enough to report issues on GitHub or Trac (let’s be honest, no one reports plugin issues on Trac), there’s really no way to get user feedback to improve these featured/official plugins.
Conclusion:
Still developers wants to know more about why WordPress Considers Historic Development Change should be?
