WordPress Unplugged

Website owners often go WordPress plugin crazy. Plugins do so much, so quickly, so easily — from adding image galleries to keeping your site more secure. But plugins can cause WordPress woes: different plugs may not play well together, or, when not updated, may behave weirdly with recent WordPress versions.

So how do you know if a plugin is A-OK or D.O.A.? Glad you asked. When evaluating a WordPress plugin, Transom poses these questions:

• Is the plugin in the WordPress: Plugins Directory? The plugins there are all free, and have been vetted by volunteer geeks. Plugins not in the directory may have less oversight.
• Examine the plugin’s stats (example at right, from Co-Authors):
  • Has it been Updated in the past year?
  • Does it have lots of Downloads? (Otherwise, you’re a guinea pig — and remember, downloads are not equal to the number of sites actually using it.)
  • How are its Ratings?
  • Have the Authors written other successful plugins?
  • Do they address issues at the plugin’s Support forum? Visit the forum to read what users say and how the authors respond.
  • Do users report the plugin has Compatibility with the latest version of WordPress?

People can easily see what a plugin will do for their site, but not always what it can do to it, especially if you someday decide to stop using it (or if the plugin breaks):

• Does it come with an Uninstall option? Will it remove any extra database tables or anything else it installed?
• If your posts are full of the plugin’s custom shortcodes, how will you remove or replace them when it’s gone?

You need to know not only how to use a plugin, but also how to stop using it. Best way to do that is, before you let it loose on your live site, install the plugin on a test site:

• Download the plugin and and look at the code in the Appearance. Is it clean, well organized, and well commented? Like this excerpt from the Hello Dolly plugin:

  function hello_dolly_get_lyric() {
  	/** These are the lyrics to Hello Dolly */
  	$lyrics = "Hello, Dolly
  Well, hello, Dolly
  It's so nice to have you back where you belong
  ...
  Dolly'll never go away again";
  
  	// Here we split it into lines
  	$lyrics = explode( "n", $lyrics );
  
  	// And then randomly choose a line
  	return wptexturize( $lyrics[ mt_rand( 0, count( $lyrics ) - 1 ) ] );
  }
  
  // This just echoes the chosen line, we'll position it later
  function hello_dolly() {
  	$chosen = hello_dolly_get_lyric();
  	echo "
  
  $chosen
  
  ";
  }
  

• Does it do what you want, without producing any unwanted effects?
• Does it offer the options you want? (Does it have too many options you don’t want?)
• Does it need its own JavaScript (.js) and CSS (.css) files? Mo’ files, mo’ problems; or, in geek-speak, the more HTTP Requests a page makes, the slower it loads.
• Does the plugin load these extra files only when required, or on every page on the site, whether needed or not? (Look at the source code with the plugin activated to see if/when the plugin’s .js and .css is called.)

This plugin monitors other plugins: P3 (Plugin Performance Profiler). Fire it up to “create a profile of your WordPress site’s plugins’ performance by measuring their impact on your site’s load time.”

Always keep your plugins updated to the latest version: that’s how the authors squash code bugs and close security holes. Running older versions is an invitation to evil-ware, with directions, to have a party inside your site.

And if you use & like a plugin, don’t forget to hit it’s “Donate »” link. Just a few bucks from a lot of happy users means the authors can afford to keep their plugs free, bug-free, and oft-improved.

Notes for Coders

Plugins work great when you’re installing a site for someone else and want it easily manageable once you walk away. But if competent coders maintain the site, consider some plug-less solutions.

Often with a sprinkling of PHP savvy, you can accomplish a plugin’s job with far less code, and far less chance of future headaches. An example: the popular AddThis social/share WP widget weighs in at 172K. But all it really does is add this bit of HTML:

<!-- AddThis Button BEGIN -->
<a class="addthis_button" href="http://www.addthis.com/bookmark.php?v=250&username=XXXXX"><img style="border: 0;" src="http://s7.addthis.com/static/btn/sm-share-en.gif" alt="Bookmark and Share" width="83" height="16" /></a><script type="text/javascript" src="http://s7.addthis.com/js/250/addthis_widget.js#username=XXXXX"></script>
<!-- AddThis Button END -->

By inserting this HTML into the loop yourself, your users have less code-load overhead; and you get complete control of where/how it displays. Same idea with Google Analytics plugins.

A quick way to get a plugin’s HTML is to install and activate the plugin, then look at a post’s source-code and grab whatever the plugin inserts.

Remember: multiple plugs can hook and filter on the same functions, making problem-tracking more difficult. And each plugin that requires its own .js and .css files can slow page-load times, as compared to having all your CSS and JavaScript in single site-wide files. Also, a plugin’s CSS declarations might interact with or override yours. That’s why when troubleshooting a site, deactivating plugins is often your best first response.