Choosing the right WordPress plugin

Choosing the right plugin for your WordPress site is no easy task. The plugins market is well-saturated and there are many alternatives to choose from for any given task. Can we approach the problem of choosing the right plugin in a more scientific way than picking the one with the flashiest branding or promise of the most features?

When I started out with WordPress over five years ago, I was only focused on the feature set of plugins when comparing them. But as sites were built and experiences with bad plugins were had I quickly became much more discriminating of the plugins that were chosen. Here are some things to look for when choosing the right plugin.

Code size

Code size is a good marker when choosing plugins. More code generally means the author of the plugin pulled in more libraries or wrote more code to accomplish the same task as comparable plugins. When comparing plugins in this manner, I tend to use CLOC, which is available on most Linux distributions and on Mac via Homebrew.  Using CLOC is as simple as running cloc folder/ from your terminal.

As an example of the difference in code size between similar plugins, I’ve taken 8 of the largest WordPress Slider plugins* and compared their code size. The results are compiled in the graph below:

While this does not by itself mean that Meteor Slides is the best slider plugin, it certainly makes me less interested in the plugins that are on the higher end of the scale.

Code quality

Checking for code quality is no easy task. I usually browse the plugin code and hope to see some of the following:

• The plugin uses a class-based approach
• The plugin follows the WordPress coding standards
• The plugin uses Composer to handle PHP dependencies
• The plugin use NPM, Yarn and/or Bower to handle JS/CSS dependencies
• The plugin has a good amount of documentation (in a readme or external site)
• The plugin has a build process (Grunt, Gulp, Webpack, etc)
• The plugin code is easy to read and understand
• The plugin code has an ample amount of comments
• The plugin uses apply_filters() and do_action(), making it extendable with filters and hooks.

Why care about code quality?

When you add a plugin to your site, you are essentially promising yourself and your client that you will maintain the plugins functionality. Choosing a plugin full of spaghetti code and huge dependencies is a big risk, because you will not be able to solve any potential issues without a large time investment to wrap your head around the code.

Update frequency

The update frequency of a plugin is an indicator of its stability. I tend to look for plugins that follow semantic versioning and that receive a steady stream of updates. The amount of updates should correlate with the complexity of the plugin. For example, a simple plugin like Disable Comments probably does not need to be updated more than once or twice a year, while a complex plugin like Polylang, which touches a lot of core code, should receive almost-monthly updates.

You can roughly determine the complexity of a plugin by combining the code size and amount of actions and filters the plugin uses. For example, let’s compare the number of add_action() and add_filter() calls in the plugins Disable Comments, Polylang and WooCommerce.

As we can see, Polylang and WooCommerce touch a lot of core code, each having over 300 total uses of actions/filters. Meanwhile, Disable Comment only uses 30 in total.

Now that we’ve tried to differentiate between simple and complex plugins, I find this chart useful for determining whether a plugin is kept up-to-date:

Most plugins keep a changelog but few put the release dates in there. It is however simple to check the commit history on the official WordPress SVN repository for plugins or by finding the plugin on GitHub/BitBucket.

Author reputability

I find that this is one of the weakest indicators of a good plugin, because even unknown authors can produce amazing code. Nonetheless, here are some warning flags to look out for:

• Author only has one plugin
• Author is not using their real name (Users named after a company are fine)
• Low rating on WordPress.org
• Plugin does not exist on GitHub or BitBucket
• High rate of unresolved topics on WordPress.org
• Updates do not use semantic versioning

What about premium plugins?

To run the tests that check code, we actually need access to the source code, which can be tricky for premium plugins, where you’re pretty much taking a leap of faith by purchasing it. Luckily, WordPress has GPL and many plugins are fully GPL licensed, even on marketplaces like ThemeForest/CodeCanyon. In these cases, I do advocate getting a hold of the source code. After all, GPL gives us “the freedom to study how (a) program works” in order to evaluate it. I would recommend GPLDL as a good site for this. If you end up using a paid plugin, buy it to support the author, it’s in the best interests of you both.

Do you agree with this post? How do you choose plugins? Leave a comment below!

* The compared slider plugins are: Meteor Slides, Meta Slider, Image Slider Widget, Slider by Soliloquy, Huge-IT Slider, Ultimate Responsive Image Slider, Huge-IT Responsive Slider & WD Slider

Photo credit #1 #2
Icons made by Freepik, Pixel Buddha, Vectors Market & Roundicons are licensed by CC 3.0 BY