WordPress is a great CMS. For many startups and SMBs, the platform seems ideal – flexible, customizable, widely known and used, and (most importantly) approachable to a non-developer audience.
And therein lies a challenge.
See, WordPress offers a UI and functionality that lets you adjust the content, appearance and interactive features without doing any coding or design work. However, you will likely need to customize code in some way during the lifetime of your website.
Enter plugins.
Plugins make it easy to customize your site in ways the stock admin interface doesn’t allow. Unfortunately, some plugins are made in a way that can cause significant issues for your website.
A plugin with low code quality can make your site unstable, hard to fix, and difficult to customize down the road. Even if you’re not a seasoned programmer, there are ways to evaluate plugins and spot signs of poor quality.
Here are a couple of issues that seem to occur most frequently.
Bloated Code
Sloppy code files make updating and customizing a plugin a nightmare. Your developer will need to parse through a ton of unnecessary code or deal with unwieldy organization in order to make changes, debug and test it to satisfy your needs.
The more time it takes your dev to make the changes, the bigger the hit to your budget and timeline.
Ideally, each file should contain code specific to the operation of that particular class or group of functions in the code. They should also be split up into relatively medium file lengths. If you open up some of the files in the plugin and see 1000+ lines of code, that might be a challenge later.
Bolt-On Functionality
Plugins that have been around a long time may have grown organically, adding lots of patchwork fixes to implement new functionality. Evidence of this can be seen in if-statement blocks repeated after each other, over and over.
This means when your developer makes a change, there’s an increased risk that something else could break as a result (regression errors).
It can be hard to know what if-statements are related, or may affect one another. In addition to the number of if-statements, take a look at the length of code inside each if-statement block. A hundred lines of complicated logic inside each if-statement will be very difficult to parse through. Following the intent of what the code is supposed to accomplish will become harder.
The longer it takes to figure out where to make code changes, then more time (and budget) it’ll take to achieve results.
Front-End & Back-End Code Confusion
Another thing to look for is separation of back-end and front-end code. By this, I mean that any HTML markup should be in separate files away from logic code that makes decisions and processes information. The official terminology for this is separating View and Presentation layers from Controller, Logic and Model layers.
Why separate the code? When HTML is mixed in with PHP, it is just plain hard to read.
Combined code also tends to cause issues with the syntax highlighting mechanisms in most programming editors. Muddy HTML and logic also makes it difficult to backtrace what you’re seeing live on a website with what’s in the code files.
All of these issues increase the odds of making mistakes when developing.
External Resource Files
Externally loading resource files that are crucial to make the plugin work is a big issue to keep an eye out for. Common externally loaded reference files are javascript, font, style CSS, and image files.
Ideally, every part of the site should be self-contained. When you externally load in files, you’re depending on an outside party to keep those reference files unchanged and publicly hosted – forever. While this can work for common libraries like jQuery and Bootstrap, it’s not okay for small, customized javascript that is unique for that plugin, especially if it is essential to the plugin functioning.
These files are also often minimized, meaning they’ve been condensed into the smallest file length possible and as a result, are not readable by a human being – making it impossible to alter or fix issues in that file. All of the javascript files should be hosted inside the site’s directories, with both the minified and full development versions of the files being available. This makes switching between the minified and full-length development version easy when you need to have code customized or make a fix.
External resources also pose a security risk to websites, as they can provide a bridge in for hackers and malicious files.
The Right Plugin Makes All the Difference
Some plugins are small, and others are huge with hundreds of files. Whether it’s small or large, these “gotchas” can make keeping your site updated and tailored to your needs difficult.
Features and fixes will always need to be made as websites change, and you don’t want to be in an awkward position when that time comes. If a central functionality of your website is tied to a plugin that is completely unmaintainable, you’ll be forced to either start over, or pour excess time and money rectifying your vulnerability. Nobody wants to be in that position.
Choosing the right plugins for your WordPress site is an essential part of web development success. Open-source CMS’ and their plugins have a great price tag (free), but if you aren’t careful, a low price tag up front can come with considerable costs down the line.