One of the reasons we love WordPress is the immense ecosystem–including thousands upon thousands of free and paid plugins that can extend the functionality of your website.
But how do you know whether it’s a good idea to install and use a particular plugin (or for that matter, a third party theme)?
This is a question we’ve helped many clients tackle, and the short answer is: it depends. The long answer is that there’s a surprisingly complex calculus behind whether we recommend that a particular plugin be used in a particular context. Let’s unpack this answer and look at the different factors that should be considered.
Plugins Can Be Cheaper Up Front…
This is probably the simplest issue we’ll look at and for site owners with smaller budgets, it may be the overriding one. Does your budget support a robust, custom implementation of the functionality in question? It’s almost always cheaper to license a plugin than it is to build the functionality from scratch. This is especially true when considering very complex plugins that implement a raft of new capabilities for your site, such as WooCommerce. WooCommerce has spent millions of dollars developing their solution–what’s the chance that you can build something with feature parity? (If you can, you should probably market it as a WooCommerce competitor!)
Of course, even though you might want to sell something online, your scenario might be fairly simple. You might not need everything that WooCommerce has to offer. This brings us to our next concern:
…But More Complicated in the Long Run
Beyond the most simple plugins, any code which wasn’t custom-built for your website probably adds features that you don’t need. This adds complexity and surface area to the code base you’re running in production. Battle-scarred software engineers will tell you that complexity is your worst enemy when trying to maintain, extend, and secure your website.
Complexity is also more often than not the enemy of performance. In the beginning, there was the plain HTML page, and it loaded within seconds. Pretty much everything we’ve done with the Web platform since then has added functionality at the cost of speed!
So if you have a simple requirement, should you use a plugin or code the solution from scratch? This is a case where a lot of times the argument to code from scratch is stronger. To use a real world example, one of our clients had a large, complex page which took a lot of time to load. They wanted the elements at the top of the page to appear sooner, so that visitors wouldn’t have to wait a long time to use the site. They initially installed a lazy loading plugin to accomplish this, but it didn’t do a very good job because it tried to abstract a lot of complex problems into one general case. We were able to replace this plugin with some custom code that resulted in the top part of the page loading in less than one second.
What about more elaborate scenarios? It may depend on how critical the functionality is to your site, and how interconnected it is with other parts of the whole solution. While the up front cost of implementing without a plugin might be higher, in the long run, you can save time and money with a solution that contains the bare minimum of complexity and is crafted to exactly meet your needs. The custom solution here may not only be more maintainable, but may also save the users of your website a lot of time.
Plugin Support and Maintenance
When you license a third party plugin, the burden is on the third party to keep it up to date, address security vulnerabilities, ensure compatibility with new versions of dependencies like PHP, etc. When you (or your web dev) roll your own functionality, that’s your job.
Which is better? If the organization you’re licensing the plugin from is well established, financially secure, has a good track record of issuing timely updates, and appears to have a healthy future, it might be a great organization to depend on. You have to look at their support policies, the history of their business, and speak with people on their team in order to assess this.
On the other hand, if it’s just one guy and he hasn’t updated the plugin for years, don’t touch that plugin. Chances are it’s already out of date or vulnerable to attack in some way, and an absent maintainer is not somebody you want to trust the health of your website to.
To a great degree this issue comes down to a matter of trust. If you trust the author of the plugin, using their plugin is putting your money where your mouth is. That plugin author will have the ability to push updates to code on your website which can do virtually anything.
If you don’t trust a particular author, you may want your internal developers to create that functionality instead, and/or use a trusted web development agency.
When You Shouldn’t Build Your Own
This isn’t a super common case, but it bears mentioning that there are certain types of software that you generally shouldn’t try to build. The classic example is encryption–it is really hard to do encryption right. Unless you have several PhDs and 5-10 years experience, you shouldn’t build your own encryption.
You almost never would want to go implement some novel form of encryption for your website. You’d either want to find a plugin that uses a good, existing encryption library, or build a plugin that uses one.
So this isn’t really about whether to build a plugin from scratch or not, more an observation that if you do, there are elements of it that you may not develop in-house anyway!
Forking a Plugin
Finally, there is a sort of middle road, compromise approach. Instead of developing the functionality from scratch, how about forking a plugin and modifying its code to match your specific requirements? From a licensing perspective, WordPress plugins usually are made available by their authors under some version the GNU Public License, which means that you are allowed to do this, but there are several caveats:
- Under the terms of the GPL, you’ll be legally obligated to make your modifications freely available to the public.
- You absolutely need to monitor the project which you forked from, and merge any security updates it makes into your codebase. All code contains vulnerabilities, but some code gets more attention from hackers than others. If you fork a large, highly visible project, it’s likely that someone will eventually find a vulnerability in that code–it will probably get patched in the upstream project, but the onus is on you to bring the patch down to the software you actually use. Ignore this obligation at your own peril!
Overall, we look at forking on a case-by-case basis. It’s better to think of forking as similar to building and maintaining your own functionality, but in some scenarios, you may be able to leverage existing work to speed up the process.
Are you grappling with this whether to use plugins on your website, or with problems that a plugin has caused? Feel free to get in touch with us. We love to tackle this kind of challenge!