Canonical, Core, Something Plugins

For the past year or so, we’ve all been hearing this term ‘canonical plugin‘ at numerous WordCamps and in interviews Matt has conducted. I’ve struggled with understanding what this term means in relation to the WordPress ecosystem and how plugins are developed but after months of hearing Matt talk about the idea and of course, reading the recent post on the dev blog that goes into more detail, I think I get it.

The idea is to make it as easy as possible to enable people to collaborate with plugin authors. Instead of everyone going their own seperate ways, bring resources and people together to focus on a common goal, that being the canonical plugin. These plugins would be under the wings of the core development team to insure compatibility, good coding practices, and would probably excel at whatever functionality they were designed for.

Now for as long as I’ve used WordPress, the plugin ecosystem is like the free market. After awhile, end users spread the word and generally can determine plugins that are good for a specific purpose. For example, Contact Form 7 was a house hold name that I saw mentioned time and time again as an easy way to generate a contact form in WordPress. The wisdom of the crowds in this case was correct. I wonder though how the canonical system will affect the free market system the repository currently has or if nothing will happen. Do plugin developers really want to work together for the common good or do they want to do their own thing without anyone looking over them?

I have no idea how this canonical plugin system will work or how it will evolve but the core development team of WordPress has discussed the issue at great lengths and I look forward to sitting back and watching to see what the vision turns into. One thing I really like about this canonical plugin idea is that it gives the team the option to yank out specific functionality in the core of WordPress and turn it into a group developed plugin. The example I continuously bring up are the Code editors in WordPress. Personally, I think these should be removed but a number of people find them useful. I think the editors should be replaced by a canonical plugin called CodePress. CodePress would then be a built in editor on steroids with line numbers, colorful syntax highlighter and something I’d love to see, revisions or versioning.

I have a bunch of questions regarding canonical plugins that I think will be addressed in the coming weeks. First, how does a plugin become canonical? How does that plugin become non canonical? How will this system work?

As for the name, I’ve decided to stick with Canonical. Core this or core that is just ripe for confusion. I get the idea behind the relationship of these plugins with the core of WordPress but I still think this name would be bad in the long run. In the poll, I voted for Other and then left the space blank. Too bad Canonical is also big in the Ubuntu community so confusion could arise from that term as well.

I’m hoping that the canonical stuff takes off as the entire team hopes and believes it will. There is also a thread dedicated to the topic of Canonical plugins that you can find here.


14 responses to “Canonical, Core, Something Plugins”

  1. This will still give plug-in authors the option of going on their own. I assume canonical plug-ins could always be forked and adapted, and if the changes are useful/popular they will be brought back into the canonical “core” plug-in- much in the way that popular plug-ins now are brought into the WordPress core once enough people ask for them or their utility becomes obvious (think automatic update).

    I would be curious, though, to hear what @alexrabe, @Viper007Bond, or other actual plug-in developers think.

    My vote was for “core”. Every time I read “canonical” I think it’s a bit confusing.

  2. I’ve listened in on a number of these discussions and participated in one at WordCampNYC and my single biggest concern is the possibility of “King Making” here. If the WordPress community “blesses” particular plugins without a clear reason why they choose A over B, it’s going to be a source of strife and angst in the community. Further, I think there are so many similar-but-not-quite-the-same Plugins because people have different Use Cases, priorities, and approaches. And realistically, none of those are bad things.

    I think two of the criteria in this process need to be Coding Standards and some sort of Security assessment. If you know how closely a Plugin holds to the standards *and* that it has less security issues than others in the same space, the community will respond accordingly. And it gives new Plugins a chance to compete. And there’s little human involvement and potential for angst.

    In terms of Coding Standards, that can be entirely automated using CodeSniffer – Security is a bit more difficult but the concept of “security fuzzing” is well-established and there are some tools out there.

    And besides, get this going and then you can go taunt other communities *cough*Drupal*cough* and ask why they’re not doing the same… ;)

    My 0.02.

  3. @Keith Casey – You bring up some of the same concerns I have and by giving these plugins some sort of special label such as “Canonical” or “Core” or whatever it maybe you are elevating them above the rest of the plugins in the community in the eyes of the average user.

    Just because a plugin is canonical doesn’t mean it’s necessarily going to be the best at what it does. Sure that is the goal, but that doesn’t mean it’s going to happen. But unfortunately because a plugin has been anointed as canonical… they are going to view it as being the best. Right or wrong.

    Thats why I do not think labeling these plugins with some sort of special designation is a good idea. Just give the plugin itself a name and release the damn thing.

    My other issue is support. Who is going to support these canonical plugins? Support is a big deal to the average user… and as someone who deals with support for a commercial plugin I shudder at the thought of supporting a plugin that may have an install base as big as a canonical plugin may have.

  4. As a plugin developer, I’m a fan of keeping the core as lightweight as possible — and having plugins for the nice-to-have features (e.g. Code Editor).

    I’m not a huge fan of the canonical plugins idea, at least the way it’s been presented thus far. A bundled/canonical plugin would have tremendous outreach, but Carl is right — providing support for a canonical plugin could prove overwhelming for the plugin developers as well as the WP core team.

    @Keith – Agreed. I think it would be of WP’s best interest to steer clear of favoritism.

    Improvements to the plugins page and “Add New” area (within WordPress itself) could make a world of difference. They’re now collecting “Plugin Compatiblity” crowdsourcing data, which could be combined with’s metric shit-ton of other statistics data to determine which plugins to feature.

    My recommendation would be for WP to re-vamp the plugins page to take all their statistics (average downloads/day, plugin age, last updated, rating, compatibility, tags) and use it to provide a more interactive/filterable experience.

    An obvious example is to allow users to search for plugins tagged with X that are compatible with Y version of WordPress. Or, plugins rated >= 75% with >= 5 votes.

    Also, cleaning up the tags system would make them more helpful. Maybe even going as far as only using tags for aspects of WordPress (e.g. “Admin UI”, “Widgets”, “Image Management”, “Search”, “SEO”, etc).

    Finally, instead of just having a single “Featured Plugins” area, maybe having a tabbed area of high-impact categories (UI, SEO, Post Types, Forms, Images, Commenting, Roles), with several algorithm-picked plugins under each type. That’ll give users a much wider view of the variety of WP plugins (no offense to PollDaddy, IntenseDebate, and the others).


Subscribe Via Email

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

%d bloggers like this: