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) 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,
Canonical Plugin and WordCamp 2022. Matt Mullenweg's appeal.
During WordCamp US contributor day this weekend, Matt Mullenweg has published a renewed invitation to the WordPress Make teams to take a plug-in approach when developing new core features. Revived the notion of canonical plug-ins, First introduced to the WordPress community in 2009 as a means of providing optional features to users with a higher level of security than regular plug-ins:
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
La WordPress plugin directory it is only one plug-in from exceeding 60.000 (at the time of publication). Contrary 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 plug-in scenarios that aren't ideal for users, such as a plug-in controlled by a single company and evolving to a pro version or removing previously free features and putting in 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 post related that inspired the renewed discussion on canonical plugins, Mullenweg weighed the controversial WebP proposal by default which had recently received new objections from core WordPress developers. Contributors worked 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 it in tomorrow's scheduled chat. It is still unclear whether recent attempts at WebP will by default point to canonical plug-in status or if some of it may 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 overcome 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.
Main contributor Torsten Landsiedel said that the difference between canonical plug-ins and plug- in of functionality she is not clear. The distinction could be that canonical plugins include ones that may never belong to the core but are still important to users.
It appears that the 'WordPress importer' plugin may be a canonical plugin. Not sure if this is a good example for a * thriving * plugin. Doesn't support featured images, struggle with high amount of posts / media, etc. The useful Health Check plug-in struggles with the missing persons 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 multiple times over the life of their website, but they are not something users might think of searching the plug-in repository or installing them at. view. Rollback is such a feature, as are site integrity, privacy export / wipe, and so on.
Stewart said.
"Formal decision making for proposals would be incredibly helpful. This topic is coming up regularly now".
Mullenweg offered nearly two dozen canonical plugin ideas for the Make teams to consider and suggested that the teams themselves could probably come up with better ideas. Imagining all these new features at 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 is easy to adopt. Early commentators on the idea raise legitimate concerns about the lack of maintainers, as history shows that support for some of the 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.