Matt Mullenweg Renews Push for Canonical Plugins

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.

15

15 responses to “Matt Mullenweg Renews Push for Canonical Plugins”

  1. ‘canonical features’ like a modern Media Library? Or like an up-to-date Admin UI/navigation?
    To me this sounds like: “we should focus on what is more important to us without wasting time considering other ideas” “for you guys, there’s the plugin way”.
    While it’s 100% true that Core shouldn’t be bloated, Matt is keep going in a close-yet-open direction community don’t always appreciate.

    • MP6 was a redesign of the WordPress admin several years back. It was a pretty huge success within the community and was ported to core. So, you’re basically using it now (just many, many iterations later).

  2. Before we go any further let’s all try to agree on the core Mission and Purpose of WP Core, and how best would those objectives be measured and maintained.

    The point is, any core feature I’m not using is effectively an unnecessary dependency. Most reasonable people would agree that keeping such dependencies to a minimum – ideally zero – is a good thing.

    Once there’s general agreement about Core’s core then it becomes clear where plugins are necessary. That increases competition (a good thing), and it removes dev fear that what they’re building won’t suddenly become Core territory.

    Unfortunately, as it is, WP has a spotty track record on such things**. Oddly enough, Matt and Automattic have played a role in that. As developer tensions rise along with alternative CMSs, perhaps those in the “executive suite” are finally feeling the heat? Nah. There’s too little history of that as well.

    ** As a result of previous experiences I’m not alone when I say I’m slow to open issues on GitHub or the bug tracker. The attitude returned is simply not motivating. I’ve got better things to do then being on the wrong end of someone else’s piss poor communication skills.

  3. Does the official importer plugins fit into this “core plugin” description? If so, I don’t hold out much hope for these new planned core plugins, because the importers are barely supported by the core team and even some of them have bugs.

  4. “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.”

    ^^ This ^^

  5. Three points

    The plugin repositories algorithm is broken, there are many great plugins but you’ll never find them. Instead you get big plugins owned by agencies trying to upsell (with huge marketing g budgets. This should be fixed first
    The keep it simple approach is the right one but it is applied inconsistently. Gutenberg is bloated and getting more bloated. Yet other areas get no love
    Wordpress actually needs better apis. But there has been zero work in this direction since Gutenberg.

    Canonical plugins are great in theory but would not really be needed if the core team just prioritised plugin developers

    • The reason why the plugin directory search isn’t improving, as well as why the many other problems with the plugin directory are not getting fixed, is that the WordPress community can’t get involved. The current team of 4 people won’t allow others to join, despite the team being in need of a lot of help. Matt Mullenweg directly employs two of the team members, so he has ample ability to get the situation changed, if he wanted.

  6. I would love to see a Canonical plugin where hybrid themes can use the Global Block User Interface. It still blows my mind that “style settings for blocks” can’t be used depending on the type of theme that you use; just in favour of FSE-themes. I suggested this kitchen sink template; but i don’t have the skills to code it myself: https://github.com/WordPress/gutenberg/issues/41119

  7. I’d love to see a canonical plugin version of ACF Pro.

    Having a canonical way to store multi-response custom fields that isn’t hidden behind a paywall would be a huge boon for the community.

    It’s also be great if it could just be bundled with core, like Akismet and Hello Dolly. And you could just delete it if you don’t need it.

Leave a Reply to MF Simchock Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: