14 September 2022

Matt Mullenweg renews the push for canonical WordPress plugins or Canonical Plugins

Can a plugin be more reliable, run by more people, and be better than other plugins in the WordPress repository? Let's discover the canonical plugins.

WordPress Plugin Canonical Canonical Plugins

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.

WordPress Plugin Repository

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.

Matt Mullenweg

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.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

JUST A MOMENT !

Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top