A few weeks back I attended WordCamp New York. While there I was asked to take part in a discussion on canonical plugins for WordPress. I had heard of the concept but not the terminology. In case you are in the same boat, to make a plugin canonical would be to mark it as the suggested plugin for a given genre.
Why do we need canonical plugins?
Currently there are around 7500 plugins in the WordPress repository. If you are looking for a plugin related to Twitter, you’ll currently get 36 pages of results. Without going through and testing a bunch of them, how do you know which ones are good? The voting system isn’t a great indicator of a plugins value because it’s too easy for a developer to game that system simply by having a group of friends all log in and give it a 5 star vote. What’s worse, a developer who creates a plugin today may not have any interest in submitting an update to the plugin in the future. If a future WordPress update causes that plugin to no longer work, users of that plugin are stuck.
I’ve heard it dozens of times over the past year, “I’m afraid to update WordPress because I’m not sure my plugins will work.” So now we have people who are willing to continue to use a version of WordPress that may have known security issues because they can’t be sure their site is going to work properly once they update. Put bluntly, that sucks!
How would it work?
Even though it’s in the early stages of planning, here are some thoughts on how WordPress might implement canonical plugins:
- Find the current “best in breed” plugin for a given genre
- Ensure that the plugin works with the most current version(s) of WordPress
- Ensure all known security “Best Practices” are implemented in the plugin
- Turn the plugin in to an open source project (ala WordPress itself), with the original developer’s OK, of course
- Prior to any new WordPress release, all canonical plugins would be tested to ensure they work properly
- When a user does a search for a plugin in a genre with a canonical plugin, it would be listed at the top of the search results and indicated as the “approved” plugin
Who benefits from canonical plugins?
First and foremost, the end users benefit the most. Especially those who might be scared to update WordPress for fear of breaking something. If all the canonical plugins go through a round of testing prior to the release of a software update, the chances of your site having issues after the update goes way down.
Developers should also benefit from it as well. Consider this: going back to my mention of 36 pages of Twitter plugins. That’s nearly 400 plugins that probably all have a base set of the same features with only slight feature differences. Rather than creating an entire plugin from scratch and flooding the repository, what if instead they produced a child-plugin that attaches to the canonical plugin and adds in the specific functionality they need. This may not be a perfect solution in every instance and a whole plugin may need to be developed from scratch. But, that’s OK. The repository isn’t going anywhere. You can still create from scratch if you wish.
So, what’s the downside?
Honestly, I can’t really think of a downside. I’m sure there will be people out there who will come up with a list of reasons canonical plugins are bad. I just can’t think of any.
When are canonical plugins coming?
As I mentioned, this is in the early stages of planning. There are definitely a ton of options to consider. Taking a complete stab in the dark, I’m guessing it’ll be summer time before this sees the light of day. There is still plenty of time to throw your ideas in the ring. If you have thoughts on how to make the system kick-ass, you can leave a comment below and I’ll see that it hits the proper channels. Or, check out this coincidentally timed post in the WordPress development blog…