Help Shape WordPress 2.9

The feature priority survey for WordPress 2.9 has been published on the WordPress development blog enabling users to pick and choose which features they would like to take higher priority over others. Results of the survey will not be published however, the anticipated feature list for WordPress 2.9 will be later on in July.

There was one question in the poll that had me scratching my head.


Every time I think I have this term canonical plugins figured out, I read something which throws my understanding out of the water. So far, my understanding of the term is that these plugins would be recommended so to speak where a number of people would be contributing to these particular plugins. However, when I read the answers to the question seen in the image above, I start to think that canonical plugins are blocks of functionality that instead of being directly in core, are actually just a plugin. In fact, I do a great job confusing myself trying to think of what the heck this all means.

So now, I have no idea what canonical means. Can someone help me out?


12 responses to “Help Shape WordPress 2.9”

  1. I dont really know but there already is a file in wordpress called canonical.php. It is in the wp includes folder.

  2. Checkout the Wikipedia explanation in the context of computer science and programming.

    Basically I think that they just mean they want to have some plugins that are the standards. Like there might be 100 gallery plugins, but one will be canonical, the default plugin. They will test those canonical plugins before major releases, so that end users can be confident that they are stable and won’t break when they upgrade.

    In this case, it seems they are referring to more “official” plugins like Akismet, but from what has been said, I get the impression that these could just as easily be third party plugins as well.

    I think this would be a good thing all around. It expands the options for end users, so that they can have confidence in those extra features, without bloat, and without taking over functionality that plugin developers have been providing.

    I can see how this would also be helpful if a canonical plugin developer was to stop development, it would be even more likely to be picked up by another developer or adopted as an official plugin. Hopefully leading to smoother transitions in these cases.

    This would be a good way to give plugin developers more of the limelight that theme developers tend to hog! But I can see how the other 99 gallery developers could feel left out in the cold…

  3. In literature anything “from the canon” is work that’s considered historic, timeless, important or otherwise required reading. Plugins that are part of the plugin canon are considered so vital to WordPress, they’re installed with nearly every site (ex: Popularity Contest, Akismet, Subscribe to Comments). Sounds like the question is asking if the important plugins should be bundled (where they can still be turned on or off) or simple coded into WP as part of the software?

  4. I believe they are using the term in the sense of canonical name (CNAME) which is an alias. As it applies to WP/WPMU, I think they are using canonical to refer to the rewrite system to provide a standard set of aliases (permalinks) that map to the actual content (ex. ?p=307).

    My take of the question is, “How do you feel about extending/adding to the rewrite rules/system to cover additional media types and/or adding them to the core?”

  5. I like the idea of extra plugins being attached to WordPress releases that allow more advanced features if enabled. It is the best way to keep WordPress from being over bloated.

    Don’t need that certain feature? Don’t enable the included plugin.

  6. A canonical plugin would be a plugin maintained by the community which would effectively be the recommended solution for whatever the plugin provided a solution to.

    These plugins would be tested alongside new WordPress releases to ensure that they are compatible.

    This allows for new chunks of functionality to be developed that are wanted by a section of the community without impacting the users who don’t want this functionality.

    It will also allow for those plugins to be updated on a different release cycle if required.

  7. If they’re just meaning should they test certain popular plugins before releasing a new versin of WP, then I saw yet. Although I assume that is already done anyway.

    If it is a question between including something in the core, or bundling a plugin, I saw stick it in the core. I don’t see much point in having something as a plugin when it’s bundled in anyway. If a bundled plugin is broken, then the core is broken since the plugin is effectively part of the core anyway (if it is bundled) … I’m not sure that entirely makes sense, but hopefully you can decipher my gibberish.

    My point is … if you are going to bundle them as plugins, they may as well be in core anyway. Although I’m still not sure that is the question they’re asking.

  8. It seems they are referring to plugins which would be bundled with WordPress, just like Akismet, Hello Dolly etc. In which case I don’t see much point, may as well bundle it with WordPress instead of doing that.

  9. @Conorp – LOL I think that has to do with conical URL’s for SEO.

    @JLeuze – Yeah, that was more in line with what I thought the term meant but I think in this case, it’s for third party plugins not necessarily plugins maintained by the core devs.

    @Darren Hoyt – I think it would be easy to figure out what those plugins are with the data the WordPress API collects from plugins installed on all of the self hosted WordPress installs.

    @Ron – Your comment actually answers Conorps suggestion of what Canonical.php is for. Don’t think aliases has anything to do with these plugins.

    @Martin – Yeah, sounds good but I don’t like the idea of extending the workload of the core developers by having to maintain these types of plugins.

    @westi – Well then, that explains it and what I was looking for. Now it makes sense.

  10. JLeuze touches on a point that I’d been considering for a while. There are many suggestions for standards for a plugin, or expected features (such as uninstall etc), so if a plugin meets all of these criteria (maybe see the wltc post), the plugin could earn a seal of approval from WP, and effectively say that it is guaranteed to work with a certain release…if that’s possible…

    I realise that’s at a bit of a tangent to your original question Jeff, but thought it was a good place to bring it up.

    @Ryan – I remember reading somewhere that plugins stay plugins because they’re not deemed necessary for everyone’s WP site to run, like the example of a gallery plugin, and instead the core is a base to be extended. The core cannot be designed to serve everyone’s different needs, hence why its core. So in my eyes, it’s best to leave this sort of stuff as a plugin. If I need it, I’ll download it.

  11. I seem to remember Matt talking about cononical plugins in State of the Word – SF, and the intention to have a canonical list for third party services and encourage devs to work together on the canonical, rather than having like 15 plugins for Twitter, and using the upcoming Profiles in this process, just like the b2 forks that came together to become WordPress.


Subscribe Via Email

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

%d bloggers like this: