Pressbits 006: How to evaluate plugins in the directory

4 Comments

Pressbits episode 006 awaits you. This time was slightly different, as Ryan and I were both on this episode. We held a very brief conversation about how we look for and decide to use a plugin in the repository.

You can listen to it here:

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

If you would rather download it directly you can do that, or subscribe to this show via RSS or on iTunes. If you would prefer a written summary, you can also read that just after the jump.

How we evaluate new plugins

This episode spawned from a conversation we were having on Skype discussing how we decide a plugin in the repository is worth downloading. Specifically, I was looking for an Amazon s3 integration plugin.

Ryan recommended one to me that I had already ignored because it only had a three star rating. Ryan doesn’t look too much at the star ratings, as he (well both of us really) considers them flawed. I don’t look at them exlclusively, but do tend to use the star rating as a simple early filter.

We both pay close attention to when a plugin was last updated, and what version of WordPress it is compatible to. Ryan tends to jump to the forum for a given plugin earlier than I do, and I tend to put more weight on downloads than he does.

Also, neither of use are ashamed to crowdsource for opinions and ideas via Twitter, when necessary.

How do you decide a plugin is worthwhile? Do you use the same methods as we do, or do you just look at the code, or do you do anything at all?

4 thoughts on “Pressbits 006: How to evaluate plugins in the directory

  1. In addition to the tips above, I check the author. There are many authors releasing tons of plugins who I can rely to and this is a great reference.

    Also, there are plugin submissions from companies who invest seriously. This could be dangerous financially wise in the future, but normally it makes the product more trustworthy IMO.

    Also check the support forums and stackoverflow on complaints about the plugin. If it’s generally clean, we’re good to go.

  2. If I know the author (chances are pretty good), then that’s all I tend to check. If it doesn’t work in the way I want, then I can usually modify it to be better and send the author a patch.

    Most of the rest of the time, I browse through the code for a few minutes. Getting a feel for the style of it, the way it’s written, etc. Don’t need to go through every line to see if it’s a well written plugin or not, just a brief once-over the code will usually do the job.

  3. I don’t tend to take notice of the ratings either. Simply because there’s no harm in trying right?

    Lots of plugins I use have no ratings, but they’re up-to-date, supported and work. Other plugins I use have poor ratings but it’s about a feature irrelevant to me or it’s a simple fix that people didn’t know how to implement.

    Then there are plugins I’ve used which have been rated full stars but I think are terrible!

    Conclusion; no harm in trying! I do rate plugins myself though, especially if I’m really happy with one.

Comments are closed.