14 Comments


  1. @Oliver Schlöbe – Not yelling, just surprised that so many people actually look at the tags of a post. I guess I do sometimes but it’s nice to know people read those.


  2. 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.


  3. Same comment about “canonical”. Doesn’t mean a thing to me, except for a biblical aspect that has nothing to do with the stuff.


  4. @Devin – I can’t wait. It’ll cut down on the pointless forks or authors not accepting patches, abandoned popular plugins (see Podpress), etc.


  5. 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 – http://urbangiraffe.com/articles/wordpress-codesniffer-standard/ 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.


  6. I think moving some functionality out of WP and into plugins would be a great way to streamline the software.

    But I do wonder if this could be an attempt to keep the commercial plugin market from developing further. Just a thought.

  7. Carl Hancock

    @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.


  8. 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 WP.org 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 WP.org’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).

Comments are closed.