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, Mullenweg weighed in on the controversial WebP by default proposal that had recently received new objections from WordPress lead developers. Contributors have been working feverishly to revise their approach in time for 6.1.

Mullenweg recommended these new features as a prime candidate for the canonical plugin pathway, suggesting it would give more time for the ecosystem around WebP to mature:

 I am interested in supporting new formats and improving performance, but I think this change being pushed by default to users when they upgrade to 6.1 is a lot for right now, including with some of the clunky interactions OSes still have around webp (and HEIC!) files.

I’m happy for support for working for webp and HEIC files to stay in core, as we should be liberal in what we accept and work with, but not with the change to convert everything to webp when JPEGs are uploaded.

The Performance team plans to discuss this in tomorrow’s scheduled chat. It’s not clear yet whether the recent WebP by default efforts will be punted to canonical plugin status or if some part of it may still land in 6.1.

Responses to the call for more canonical plugins were mixed, as some immediately recognized the increased burden on maintainers of these plugins.

“WP just needs to get over it’s aversion to optional features,” WordPress developer Jon Brown said. “Features that can be enabled/disabled. ‘Decisions not options’ is a great ethos when it’s about keeping things simple for users but it seems to have been thrown out the window with Gutenberg UX, and turned into axiom when discussing adding trivially simply options to the settings page.”

iThemes-sponsored contributor Timothy Jacobs said he is not necessarily in support of adding more options to Core but thinks canonical plugins could be presented in a similar way to options.

“That doesn’t mean the UI has to be just searching through the plugins directory for something you want,” Jacobs said. “The canonical plugins could be exposed in maybe a ‘settings-like’ UI. I think Import methods are a bit hidden away in the Tools menu, but something like that perhaps.”

Core contributor Torsten Landsiedel said the difference between canonical plugins and feature plugins is not clear. The distinction may be that canonical plugins include those that may never belong in core but are still important for users.

“It sounds like the ‘WordPress importer’ plugin could be a canonical plugin,” Landsiedel said. “Not sure if this a good example for a *thriving* plugin. Does not support featured images, struggles with high amounts of posts/media, etc.

“The useful Health Check plugin struggles with missing people helping out.

“How do we prevent those plugins (whatever called) from not getting enough contributors? I think an importer is a crucial tool, but also not necessary in core (I can install it if I need it, that’s okay) – but it should work and at the moment this does not work well. But I don’t see much interest from the dev community to help fix this (maybe because they use WP CLI and do not care about this plugin?)”

WordPress core contributor Colin Stewart said that while he agrees features as plugins first is useful for new features, it requires “a much better metric than ‘runaway success,’ for inclusion in core.

“Some features are important for stability, and protect users from issues that give them a headache multiple times during their website’s lifetime, but aren’t something users might think to search for in the plugin repository, or install on sight,” Stewart said. “Rollback is such a feature, as is Site Health, Privacy Export/Erase, and such.

“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 the Make teams could consider and suggested the teams themselves could likely come up with better ideas. Imagining all these new features in play, it would be like a renaissance of innovation in the admin. This is an exciting prospect that could benefit WordPress users as long as the plugins are featured in such a way that they are easy to adopt. Early commenters on the idea raise legitimate concerns about the lack of maintainers, as history shows support for some of the existing canonical plugins is somewhat patchy.

“I hope it sparks discussion at contributor day and beyond on how we can utilize plugins better to increase the speed of evolution for WordPress, keep core light, fast, and opinionated, and do so while saying ‘yes’ to more ideas and experimentation,” Mullenweg said.