WordPress Plugins – The Good, The Bad and the Ugly

<Cue Ennio Morricone’s theme from The Good, the Bad and the Ugly>

For most of the problems I see in WordPress, we’ve got no one to blame but ourselves.  I get a lot of emails, calls, etc. and they generally come down to one thing: plugins that are improperly configured or are causing conflicts with other plugins.

I typically run my WordPress installations with around 5-6 plugins, all installed to provide very specific functionality and all of which I have closely reviewed to make sure they’re going to do what I want them to do, and not bring “other functionality” to the party that I don’t want.

Before we start, I should probably offer a definition of what wordpress plugins are:

 A Plugin is a group of php functions that can extend the functionality present in a standard WordPress weblog. These functions may all be defined in one php file, or maybe spread among more than one file. Usually, a plugin is a php file that can be uploaded to the “wp-content/plugins” directory on your webserver, where you have installed WordPress. Once you have uploaded the plugin file, you should be able to “turn it on” or Enable it from the “Plugins” page in the administration interface of your weblog. The WordPress source code contains hooks that can be used by plugins. <from the WordPress Codex Glossary http://codex.wordpress.org/Glossary>

Fairly benign, eh?  Well we should remember these, along with, to a lesser degree, theme files, the main way in which we extend the functionality of the WordPress system. Anything from adding a Facebook “Like” button to adding on a full user management system.

My argument against using too many WordPress plugins isn’t the one you’d expect.  I don’t worry about plugins slowing websites down.  Look at WordPress.com – they use 200 plugins per page load (*I should note this is second hand info from Wordcamp SF this year).  If plugins are slowing page load, then it’s due to your use of poorly coded plugins.

My argument against excessive plugin use comes down to this:

  • Plugin Conflicts – the more you’ve got, the more likely your’re going to have something go horribly wrong.
  • Debug Nightmares – There’s a showstopper bug and the site is running 30 plugins. Have fun, Mr. Developer…
  • User Experience – the more you modify the system, the more you’re going to have trouble training new users.  I should also point out that training is generally an ongoing issue for companies.
  • The Bad Apple Affect – even with a modicum of due diligence on your part, it’s possible your going to let a bad plugin slip through the vetting process.
  • Most Plugins Aren’t Essential – and a very high percentage are never, ever used by the customer.  So why are they there?

So what makes a good wordpress plugin? My general list:

  • Simplicity – something that provides the fuctionality I need and not much more.
  • Popular Acceptance – if the rest of the community is using the thing, then we can reasonably expect the developer will continue support.  Even if the developer doesn’t, there’s a good chance someone else will, if the need arises, as notably happened when the original develop of All in One SEO gave it up, and the development responsibilities were picked up by hallsofmontezuma.  Just because lots of people use a plugin doesn’t mean it’s good, but it does increase the likelihood.
  • Code Accessibility – (for major functionality) it has become a practice for some commercially developed plugins to user obfuscated (encrypted) code to protect their intellectual assets.  I support their right to do that, but I will do everything in my power not to use plugin that doesn’t allow me code level access.  Just last week I was debugging an issue for a customer, and found the bug was in code that had been obfuscated.  We’d already found we had trouble getting support from the plugin supplier, so we were essentially at a road block.  I was able to provide a work around, but there was no reason we should have had to do that.
  • General Manners – if the plugin inserts links into my site to itself without providing a way to turn them off easily, or if it adds a feed from the developers site into my admin console without providing a way to turn it off, I won’t use it.

My general rule when it comes to plugins is this: Know what functionality you need, why you need it, and how the plugin provides it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>