Have you read the latest post of Matt Mullenweg? Yes, one of the founding developers of WordPress. Today, he came out with an interesting post, revisiting what was once coined Canonical Plugins.

Canonical Plugins are community-developed plugins developed by multiple developers, built to address the most popular and in-demand features and functionalities. These plugins would be GPL (General Public License), available in the WP.org repo, and would be designed and developed in close association with WordPress Core.

Well, the most interesting part about this whole thing is that the first revelation of canonical plugins surfaced in 2009, in a post by Matt himself. And the mystical concept and idea has resurfaced again, 13 years later!

Canonical Plugins, Why in the First Place?

Well, the WP.org repo houses countless plugins (not really, as of 14th, September 2022, there are around 60,000 plugins. Yeah just that much ). Jokes apart, the whole thing behind these many plugins is that they are developed and controlled by a single developer or company. So, the direction, upgrades, and feature addition of these plugins depend upon the respective owners.

Thus, many features and functionalities are a miss in the free version and readily available in the paid version. This led to a divide and now plugin owners can decide who gets full access to their plugins and who doesnt. 

Why is Matt Addressing This?

Because WordPress is more like an ecosystem thriving on collective and collaborative efforts of its people with varied interests. But, they come together and create something that now commands 43% of the worlds websites. And all of this is for free, and explicitly open to everyone who wants it.

Matt believes that the WordPress community has greatly benefitted from successful canonical plugins. Yes, they have a long history, and some of the most successful ones are MP6, Gutenberg, and REST API. To add to Matts views, the community-developed plugins, called canonical, have greatly improved and changed the WordPress software we know today.

Also, it will be these canonical plugins that will become the official first choice in recommendations by core and WP.org for areas that are Core niche but can be addressed via specialized plugins!

We are reaching a point where the 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 path to come into core if the plugin becomes a runaway success. I am very conscious that when people are aiming to have something in the core, a no or not now can be frustrating and sometimes create artificial pressure to put something in before its ready, as I believe happened with the REST API in WP 4.4.

Matt Mullenweg, Founding Developer, WordPress

Matts Ideas for Canonical Plugins

Matt has come up with Canonical plugin ideas for each Make team. Lets look at them and understand what he has planned for WP.org and its future.

1. Design: More admin themes.
2. Mobile: (not sure)
3. Accessibility: An alternative API-based admin designed for accessibility and simplicity.
4. Polyglots: Inline translation submissions for core and plugins and themes.
5. Support: Related threads or documentation pages dynamically loaded from w.org for the help dropdowns on every page.
6. Documentation: Experiment with adding more inline documentation to wp-admin interfaces. Gather opt-in stats on what is actually read and used, which links to .org get clicked on.
7. Themes: Better previews of theme customizations, and activation workflows that allow customization of colors/images/typography.
8. Plugins: Inline rating and feedback for plugins, crash, and compatibility data reporting back.
9. Community: Experiment with the dashboard widget that promotes events to call to action for organizing when theres not a local meetup, and better incorporate online events including workshops and cohort classes.
10. Meta: Login with a .org login account. Dashboard with all of your linked WPs on w.org. Monitor versions, install plugins with one click, etc.
11. Training: Courses or training in every help dropdown.
12. Test: Opt-in JS or PHP error catching that reports back to a tracking server.
13. TV: Integration with help dropdowns, and inline tutorial videos.
14. Marketing: Widgets and blocks for people to link back to W.org, like super-charged powered by, and promote their liked or favorite plugins and themes.
15. CLI: N/A.
16. Hosting: Experiment with standard hooks, icons, and menu items for hosts to link or embed things like email, domains, and contacting support.
17. Tide: Show the data in more places in wp-admin.
18. Openverse: Should actually just come into core more, but perhaps a plugin would be a good place to experiment with submitting something to Openverse and CC licensing any media upload. Community and collaborative tagging of uploads and Openverse items.
19. Photos: Similar to Openverse, make it possible to submit uploads and search the directory.
20. Core Performance: WebP conversions for new uploads and batch processing to convert old images. Show before-after space usage and page performance. (Previous post on WebP in 6.1 that inspired this.)

This is not meant to be an exhaustive list, and Im sure the teams themselves could come up with much better ideas and options, but 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

Matt Mullenweg, Founding Developer, WordPress

How is the WordPress Community Responding?

Canonical plugins sound great, but is it a disaster in disguise or a boon waiting to be uncovered?

The community has taken varied stances towards this post and has shared their opinion on the same. Ill share some below:

A simplified admin specifically targeted for accessibility would be a potential civil rights violation per Brown v. the Board of Education; offering a separate experience with the idea that it is the mechanism for a specific group of users is a serious problem. There is room for having user experience paths that are simplified, but that wouldnt in any way change our needs for the main WordPress admin. Maintaining separate systems with feature parity is not feasible.

Joe Dolson

WP just needs to get over its aversion to optional features. Features that can be enabled/disabled. Decisions not options is a great ethos when its 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 simple options to the settings page.

Things that out to be features, or canonical plugins, that can be enabled or disabled
Comments
Classic Editor
SMTP Email Support
Full DAM style replacement for Media Library
Notification Center (maybe this should just be core)

Admin:
I will say I dont think we need more admin themes. The problem with the admin is the chaotic UX once plugins are added not the design. There are no standards enforced and hence we get cluttered chaos.

For too many basic options the answer for far too long has been there is a plugin for that. Heck folks suggested the answer to the WebP concerns was a plugin to disable WebP generation instead of an single checkbox on media settings.

Plugins too often these days bring with them admin banner ads, review request popups, and way over complicated options that dont follow WP UX guidelines and look like embedded 3rd party web apps. Its a mess.

Disable Comments is a great example where a simple option in core would avoid a giant garbage heap of needless options added by a plugin, but there are dozen more examples.

 

Jon Brown

Will Canonical Plugins Make a Difference?

According to Matt, the relation between Core and Canonical Plugins would be very strong. And it is this connection that would ensure:

a) The plugin code would be secure and the best possible example of coding standards

b) That new versions of WordPress would be tested against these plugins prior to release to ensure compatibility

Matt also plans to have a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editors Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security, and support.

To have a system like this, each canonical plugins development community would probably need a similar infrastructure to WordPress itself, including things like Trac, mailing lists, support forums, etc.

My Thoughts (Because, why not?)

Well, firstly I believe its a good idea, so kudos to Matt for that. But I feel this wouldve panned out a much better way and direction, had it been implemented the first time canonical plugins were coined and introduced.

13 years later, the WordPress software and community have progressed greatly and have taken a very different stance and shape. Bringing such monumental changes just might harm the communitys sentiments, as it directly clashed with the business interests of many developers, teams, and companies.

Yes, honestly we have to consider the fact that we are WordPress solution providers, and as options shrink, it just might make people opt out of WordPress. Also, as canonical plugins come in, it would require more teams to work, thus, taking more resources to develop a feature/functionality instead of the core software itself.

These are just some of the thoughts that are running on top of my mind, Ill give a detailed opinion once I get more updates and directions about Matts take and decisions on canonical plugins.

But, as this is just a healthy discussion, it will be some time to see what shape this takes and where it heads off to. Till then, this is your host, signing off (to search for the next article topic ). Subscribe to our newsletter, as interesting articles are right across the street. Take care, friend!