Table of contents of the article:
There have been a lot of references to "canonical plugins" from 2009 to present, especially at Matt's WordCamps, but we haven't published anything official about the idea, nor have we made much progress beyond discussions about how great it would be to have canonical plugins and how much it would be nice for the community.
What is a Canonical WordPress plugin, or a Canonical Plugins.
This is one of the many things the core commit team has been talking about in the last few days and everyone agrees that we need to prioritize this aspect of the project sooner rather than later. So here's a top notch description of how we're currently thinking about canonical plugins, which we'd like to use to start a focused community discussion on the topic.
Canonical plugins would be community-developed plugins (multiple developers, not just one person) that address the most popular feature requests with superior execution. These plugins would be GPL-certified and reside in the WordPress.org repository. They would be developed in close collaboration with the WordPress core. There would be a very strong relationship between the core and these plugins, ensuring that a) the plugin's code was secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins before release to ensure compatibility. There would be a screen within the Plugins section of the WordPress admin to present these canonical plugins as a sort of publisher-selected or verified guarantee. These plugins would be a true extension of the WordPress core in terms of compatibility.
Canonical Plugin and WordCamp 2022. Matt Mullenweg's appeal.
During WordCamp US's Contributor Day this weekend, Matt Mullenweg issued a renewed call for WordPress Make teams to adopt a plugin-first approach when developing new core features. He revived the concept of canonical plugins, first introduced to the WordPress community in 2009 as a way to provide optional functionality to users with a higher level of security than regular plugins:
Canonical plugins would be community developed plugins (multiple developers, not just one person) and respond to popular feature requests with superlative execution. These plugins would be GPL and reside in the WordPress.org repository and would be developed in close connection with the WordPress core. There would be a very strong relationship between the core and these plugins which would ensure that a) the plugin code was secure and the best possible example of coding standards and b) that new versions of WordPress would be tested against these. plug-in before release on ensuring compatibility. There would be a screen within the WordPress admin plugins section to present these canonical plugins as a sort of guarantee of the publisher's choice or verified. These plugins would be a true extension of the WordPress core in terms of compatibility,
Jen Mylo
The WordPress Plugin Directory is just one plugin away from surpassing 60.000 (at the time of publication). Contrary to the idea of canonical plugins, the official directory is still a wild west in terms of what users can expect from plugin authors. Mullenweg cited several plugin scenarios that aren't ideal for users, such as a plugin controlled by a single company and evolving to a pro version, or the removal of previously free features and the inclusion of an update.
Canonical plugins are meant to provide a reliable alternative to plugins where the authors' motives may not put users first. It also provides an avenue for top contributors to demonstrate the demand for functionality they want to achieve in WordPress. Some projects like MP6, Gutenberg, and the REST API have brought this path into the core.
We are reaching a point where the core needs to be more editorial and say 'no' to features that come ad hoc as they sometimes do, and my hope is that more Make teams will use this as an opportunity to influence the future of WordPress through a plug-first approach that gives them the luxury of faster development and release cycles (instead of three times a year), less revision overhead, and a path to core if the plug-in becomes an overwhelming success,
Mullenweg said.
I am very aware that when people aim to have something in their core, a 'no' or a 'not now' can be frustrating and sometimes create artificial pressure to insert something before it is ready, as I believe happened with the REST API in WP 4.4.
In a related post that inspired renewed discussion about canonical plugins, Mullenweg weighed in on the controversial WebP-by-default proposal , which had recently received renewed objections from WordPress core developers. Contributors have been working feverishly to revise their approach in time for 6.1.
Mullenweg recommended these new features as a great candidate for the canonical plugin path, suggesting that it would allow more time for the ecosystem around WebP to mature:
I'm interested in supporting new formats and improving performance, but I think this change sent by default to users when they upgrade to 6.1 is a lot for now, even with some of the clunky interactions operating systems still have around webp ( and HEIC!) file.
I am happy that the work support for webp and HEIC files remains in the core, as we should be liberal in what we accept and work with, but not with the modification to convert everything to webp when JPEGs are loaded.
The Performance team plans to discuss this in tomorrow's scheduled chat. It's unclear whether recent WebP efforts will default to canonical plugin status, or whether some of it might still make it to version 6.1.
Responses to the demand for more canonical plug-ins have been mixed, as some immediately recognized the increased burden on maintainers of these plug-ins.
“ WP just needs to get over its aversion to optional features ,” said WordPress developer Jon Brown.
Functions that can be enabled / disabled. “Decisions not options” is a great ethos when it comes to keeping things simple for users, but it seems to have been thrown out of the window with Gutenberg UX and turned into an axiom when discussing adding trivially simple options to the settings page.
IThemes-sponsored contributor Timothy Jacobs said he's not necessarily in favor of adding more options to Core, but he thinks canonical plugins could be presented similarly to options.
That doesn't mean the user interface simply has to search the plugin directory for something you want, ”Jacobs said. “The canonical plugins could possibly be exposed in a 'settings-like' user interface. I think the import methods are a bit hidden in the Tools menu, but maybe something like that.
Core contributor Torsten Landsiedel stated that the difference between canonical plugins and feature plugins is unclear. The distinction might be that canonical plugins include those that may never become part of the core but are still important to users.
It looks like the WordPress importer plugin might be a canonical plugin . I'm not sure this is a good example of a *thriving* plugin. It doesn't support featured images, struggles with large post/media counts, etc. The helpful Health Check plugin struggles with missing people they help.
Landsiedel said.
How can we prevent those plugins (whatever it is called) from not getting enough contributors? I think an importer is a crucial, but not necessary tool in the core (I can install it if I need it, okay) - but it should work and it doesn't work well at the moment. But I don't see much interest from the developer community to help fix this (maybe because they use WP CLI and don't care about this plugin?)
Lead WordPress contributor Colin Stewart said that while he agrees that features as a plugin are useful for new features, it requires "a much better metric than" overwhelming success "for inclusion in the core."
Some features are important for stability and protect users from issues that cause them headaches repeatedly throughout the life of their website, but they're not something users might think to search for in the plugin repository or install on the fly . Rollback is one such feature, as are site integrity, privacy export/clearance, and so on.
Stewart said.
“ A formal decision-making process for proposals would be incredibly helpful. This topic is coming up regularly now .”
Mullenweg offered nearly two dozen ideas for canonical plugins that the Make teams could consider, and suggested that the teams themselves could likely come up with better ideas. Imagining all these new features in play would be like a renaissance of innovation in administration. This is an exciting prospect that could benefit WordPress users, as long as the plugins are presented in a way that makes them easy to adopt. Early commentators on the idea raise legitimate concerns about the lack of maintainers, as history shows that support for some existing canonical plugins is somewhat patchy.
I hope it ignites a discussion during contributor day and beyond about how we can better use plugins to increase WordPress evolution speed, keep the core light, fast and opinionated, and do it by saying 'yes' to more ideas and experimentation.
Mullenweg said.
