Matt Mullenweg Re-Pushing the Spec Plugin – WP Tavern

During this weekend’s Contributor Day at WordCamp US, Matt Mullenweg reiterated his call for WordPress to let teams take a plugin-first approach when developing core new features. He revives the concept of canonical plugins, which was first introduced to the WordPress community in 2009 as a means to provide users with optional features with more confidence than regular plugins:

Canonical plugins will be community-developed plugins (multiple developers, not just one person) and address the most popular feature requests with top-level execution. These plugins will be GPL and live in the WordPress.org repository and will be closely tied to the WordPress core. There will be a very tight relationship between the core and these plugins to ensure that a) the plugin code is safe and the best example of coding standards, and b) new versions of WordPress will be tested against these plugins before release to ensure compatibility sex. The Plugins section of the WordPress admin will have a screen to list these canonical plugins as an Editors’ Choice or Verified Guarantee. These plugins will be true extensions of core WordPress in terms of compatibility, security and support.

Jen Mylo – Canonical Plugin (Say What?)

The WordPress plugin directory is just one plugin away from over 60,000 (at the time of publication). Contrary to the idea of ​​canonical plugins, the official directory still feels like the wild west in terms of what users expect from plugin authors. Mullenweg cites several plugin scenarios that are not ideal for users – such as a plugin controlled by a company and evolving to be closer to a pro version or removing previously free features and putting them behind an upgrade.

Canonical plugins are designed to provide a trusted alternative to plugins whose authors’ motives may not put users first. It also provides a way for core contributors to demonstrate their needs for features they want to land in WordPress. Several projects such as MP6, Gutenberg, and REST API have brought this path to the core.

“We’ve gotten to the point where the core needs to be edited more and say ‘no’ to features that pop up on an ad hoc basis like sometimes, and I hope more Make teams take this as an opportunity to influence the future of WordPress by A plugin-first approach that gives them faster development and release cycles (instead of three per year), less review overhead, and a way to get to the core when plugins are hugely successful,” Mullenweg said.

“I know very well that when people’s goal is to have something in the core, ‘no’ or ‘not now’ can be frustrating, sometimes creating artificial pressure to put it in before it’s ready, As I believe happened in REST API WP 4.4.”

In a related post that sparked a renewed discussion about canonical plugins, Mullenweg weighed in on the controversial WebP default proposal, which recently received fresh objections from WordPress’ main developers. Contributors have been working feverishly to revise their approach in time for 6.1.

Mullenweg recommends these new features as prime candidates for the canonical plugin pathway, suggesting that it will give the ecosystem around WebP more time to mature:

I’m interested in supporting new formats and improving performance, but I think this change will be pushed to users by default when they upgrade to 6.1, including that the OS still revolves around webp (and HEIC!) files.

I’m happy to support working for webp and HEIC files to keep core as we should be free to accept and use what, but don’t support changes to convert everything to webp when uploading JPEG.

The performance team plans to discuss this in a scheduled chat tomorrow. It’s unclear if the recent WebP default effort will be put into canonical plugin status, or if parts of it will still be present in 6.1.

Calls for more canonical plugins had mixed responses, as some immediately realized the increased burden on maintainers of these plugins.

“WP just needs to get over its aversion to optional features,” says WordPress developer Jon Brown. “Features that can be enabled/disabled. ‘Decisions not options’ is in good spirit as it is meant to keep the user simple, but it seems to have been thrown out the window by Gutenberg UX, with discussions on adding simple to the settings page option becomes an axiom.”

Timothy Jacobs, an iThemes-sponsored contributor, said he doesn’t necessarily support adding more options to Core, but thinks canonical plugins could be presented in a similar fashion to options.

“That doesn’t mean the UI has to just search the plugin directory for what you want,” Jacobs said. “The canonical plugin might be exposed in a ‘settings-like’ UI. I think the import method is a bit hidden in the tools menu, but it might be.”

According to core contributor Torsten Landsiedel, the distinction between spec plugins and feature plugins is not clear. The difference may be that canonical plugins include those that may never be part of the core but are still important to users.

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

“It’s hard to help missing people with a useful Health Check plugin.

“How do we prevent those plugins (whatever they are called) from not getting enough contributors? I think the importer is a vital tool, but not required in the core either (I can install it if needed, that’s ok) — — but it should work, but currently it doesn’t work very well. But I don’t see much interest in the development community to help with this (maybe because they use the WP CLI and don’t care about this plugin?)”

WordPress core contributor Colin Stewart said that while he agrees that having functionality as a plugin is useful for new features in the first place, it needs “a better metric than ‘runaway success’ to be included in core.

“There are features that are important for stability and protect users from issues that give them headaches many times over the life of a site, but users might not think to search or install in the plugin repository,” Stewart said. “Rollback is one such feature, as are site health, privacy export/wipe, etc.

“A formal decision-making process for proposals would be very helpful. This topic comes up quite often now.”

Mullenweg provided nearly two dozen ideas for spec plugins that the Make team could consider, and suggested that the team themselves might come up with better ideas. Imagine all these new features in action, it’s like a renaissance in management innovation. This is an exciting prospect that could benefit WordPress users as long as the plugin is presented in an easy-to-adopt manner. Early commenters on this idea raised legitimate concerns about the lack of maintainers, as history suggests that support for some existing spec plugins is somewhat incomplete.

“I hope it sparks discussion at Contributor Day and beyond about how we can better leverage plugins to speed up WordPress, keep the core light, fast and opinionated, and say ‘yes’ to more ideas and experiments Do it at the same time,” Mullenweg said.

Leave a Comment

Your email address will not be published.