During WordCamp US’ contributor day this weekend, Matt Mullenweg published a renewed call for WordPress’ Make teams to adopt a plugin-first approach when developing new features for core. He revived the notion of canonical plugins, first introduced to the WordPress community in 2009 as a means for delivering optional features to users with a higher level of confidence than regular plugins:
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. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core. 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. There would be a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editor’s Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security and support.
Jen Mylo – Canonical Plugins (Say What?)
The WordPress Plugins Directory is just one plugin away from crossing 60,000 (at the time of publishing). In contrast to the idea of canonical plugins, the official directory is still like the wild west in terms of what users can expect from plugin authors. Mullenweg cited several plugin scenarios that are not ideal for users – such as a plugin being controlled by a single company and evolving to go more towards a pro version or removing previously free functionality and putting it behind an upgrade.
Canonical plugins are meant to provide a trustworthy alternative to plugins where authors’ motivations may not put users first. It also provides an avenue for core contributors to demonstrate the demand for features they want to land in WordPress. A few projects like MP6, Gutenberg, and the REST API have taken this path into core.
“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 and path to come into core if the plugin becomes a runaway success,” Mullenweg said.
“I am very conscious that when people are aiming to have something in core, a ‘no’ or ‘not now’ can be frustrating and sometimes create artificial pressure to put something in before it’s ready, as I believe happened with the REST API in WP 4.4.”
In a related post that inspired the renewed discussion on canonical plugins,
[…]
This article was written by Sarah Gooding and originally published on WP Tavern.