The Truth About WordPress Plugins

The objective of this article is to discuss the truth about WordPress plugins, both their advantages, disadvantages, and the reality of plugin usage. There are a lot of misconceptions about WordPress plugins, and my primary goal is to share my views, based on my real world experiences with WordPress plugins (both free and premium). It’s extremely important to be upfront and also state that while a lot of my statements are general statements, I obviously have not tested every single use case for every single plugin in the WordPress ecosystem.

The Advantages of Using WordPress Plugins

I think the advantages of using WordPress plugins are pretty clear – grab a plugin instead of writing some code. From the outside looking in, it appears to be a very clear case of “saving time and money.”

While this can be true, it’s important to note that not all plugins are created equal and not all of the developers that create them code with equal quality, care, and future support in mind. I, too, was once a fledgling WordPress site administrator, and I, too, consistently reached for a plugin when I wanted to add a feature or functionality to my site. It was the easy solution, so why wouldn’t I? I, too, ran sites with 10, 20, 30, or even more plugins on them. It’s because of this naivety that I also learned the disadvantages of using WordPress plugins.

The Disadvantages of Using WordPress Plugins

While the advantages of WordPress plugins are easily seen, the disadvantages are often not. For this reason, I want to break up these disadvantages and go through them with you to help you learn from my years in the trenches with WordPress – from a site administrator, developer, architect, and systems administrator perspective.

Security & Vulnerabilities

I can’t stress this one enough. Also, it’s important to note that this same scenario can be true of all libraries, plugins, modules, frameworks, packages, etc. in the open-source ecosystem (not just WordPress).

When a WordPress plugin is created, the entire project is in the hands of the plugin developer. WordPress doesn’t have a security team on stand-by that goes through each and every WordPress plugin’s code line-by-line; and it’s unrealistic to expect this of WordPress core development team.

For this reason, when you add a plugin, you just put the security of your project in the hands of a nameless individual/team that has absolutely no idea about any aspect of your project – what it does, who it serves, and its existing architecture. This means that your project’s security is now only as secure as that nameless developer’s experience level, security knowledge, and effort that they are willing to put into the plugin. In my opinion, this is an extremely dangerous game to be playing.

Developer Support, Updates, & WordPress Core Breaking Changes

This partially goes hand-in-hand with my statements above regarding security and vulnerabilities. When you download a WordPress plugin and use it in your project, you have no way of truly knowing whether or not the developer has intentions of continuing development of the plugin.

You don’t know what their plans are for making sure that it’s continuously updated to ensure stability and security. You also don’t know whether or not they are staying up-to-date with WordPress core’s current changes, roadmap of feature releases, deprecated functions, and/or breaking changes.

If a plugin author (plugin developer) isn’t supporting their plugin properly, a lot can go wrong. They could release an untested version update that breaks your site. They can release an untested version that includes previously deprecated WordPress functions, hooks, etc. that will cease support by WordPress in the future. They could release a plugin update that includes vulnerabilities that expose your site to malicious attacks through injections and/or expose a backdoor to your website’s directories. Or maybe they stop releasing updates altogether.

Scalability

Not all developers and engineers are equal in skill and experience, and that bleeds into everything that they create, including plugins. You might really like what a plugin does on a demo site, and love it even more when you add it to your own WordPress site, but in reality, unless you set up the proper testing procedures and execute your testing measures, you won’t know that the newfound plugin is a potential website murderer at scale until it’s far too late.

A plugin might work completely fine at 1,000 daily active users but completely crash your site at 100,000 daily active users, or even as little as 5,000 daily active users.

Future Project Plans

While not the same circumstances as scaling, future-proofing also requires you to consider what the immediate future plans are for your project, as in the features you are planning on adding in the near future.

When an engineer is planning out a project, they will typically take into account all of the potential future features that the project owner is planning and/or considering. They then also take into account past experiences with similar functionality on previous projects. We do this to ensure that when we are architecting a site, we are doing our best to make sure that nothing we do today will impede on our ability to meet the future plans and goals of the project.

A plugin developer simply can’t do that when they are not involved in your project.

Code Bloat

I’ve read a lot of articles that discuss the pros of plugins, the cons of plugins, and even some that discuss both the pros and the cons of WordPress plugins, however they all seem to leave out one important (in my opinion) matter – code bloat.

Put simply, code bloat is what we consider excess code that is not needed for the project. It's code that doesn’t serve an immediate purpose or need for the project’s objectives. Code bloat exists in one form or another in almost every single plugin that exists. How is this, you might ask? I’ll walk you through the simplest of examples, and you can expand on it in your own mind.

Let’s say you aren’t a web developer (or you are, but you’re a lazy developer or a developer with no time) and you want to add a really cool carousel slider to showcase some products inside of a blog article. Since you aren’t a developer, you decide to go look for WordPress slider plugins. Holy shit, the options are endless. There’s hundreds of them. Some are free and some cost money.

Lucky for you, you found a really awesome one that has border options, navigation options, the ability to create multiple sliders, and all kinds of really super cool features. But the best part is that it’s free. Winner winner chicken dinner!

When you install the plugin, you start configuring the plugin, playing with the options, you set everything up, and then you start creating your first slider, and then finally, voila, you’ve created an awesome product slider that showcases four really cool products within your featured blog article. Life is good.

What isn’t obvious is that all of those configuration options and settings are created with code. That code was created generously by the plugin developer. They wrote that code because they wanted to make sure that their plugin would help a massive amount of different users, with various needs. They graciously did this out of the goodness of their heart, because as a developer, they know how much plugins like this can help others. They legitimately had nothing but the best intentions in mind.

The only problem is that all of that code written to help all those people with all those needs becomes code bloat. It’s unnecessary code inside of your project and it has to run to do its different checks when deciding what to do for your specific needs (based on your configuration settings, etc.).

The reason that this matters is two-fold. The first reason I already touched on above…

“It has to run to do its different checks when deciding what to do for your specific needs.”

If the slider had been designed and developed specifically for your site, it would only need to run code that was specific to your site’s requirements. It wouldn’t need to process code that was irrelevant, which minimizes performance (albeit, minutely) and increases response times.

The second reason that this matters has to do with codebase size. While current hosting platforms aren’t as restrictive and expensive as they used to be, it’s always important to mind how large your codebase is. The smaller the codebase, the easier it is to maintain, and vice versa.

If you aren’t a developer, and you don’t have a developer on retainer, I would highly recommend trying to keep your codebase size down to avoid any potential issues that come with a larger codebase. Maintainability is something that is often overlooked by site owners and developers alike. While code bloat isn’t exactly the most imperative factor to consider, it should still be considered.

Do Plugins Play Well With Each Other?

I’ve seen a lot of comments online about plugins working well with each other, and I’ve seen a lot of comments that claim the exact opposite. The reality is that it’s all based on the plugins and the architecture of your site. Some plugins play extremely well with others and some do not. Unfortunately, there are also the scenarios where two plugins seemingly play extremely well with each other, but ultimately cause conflicts with each other down the road, and often times, without an experienced WordPress developer on hand, it can be pretty hard to trace the problem back to the root source. The only advice I can give you on this, if you have to go down this road, do your homework and do it thoroughly. It’s much better to spend a few days reading documents, forum posts, github issues, etc before introducing plugins that might potentially conflict with each other, than having thousands of your users go to your website to only be greeted with a completely white screen – aka The White Screen of Death.

When You Should Use WordPress Plugins

As an engineer, I’m not an advocate of using off-the-shelf plugins (free or paid). Here at LSM, we have only three plugins on our approved plugin list. Those are the only three plugins that are pre-approved to be added to any project that requires the features within those plugins without a thorough plugin review and approval.

One of them is a meta management plugin (SEO meta to be specific), one of them is a forms plugin (which we are in the process of replacing with our own internal developer plugin), and the third is an e-commerce plugin.

Instead, we have created several developer plugins, that act as core frameworks for certain features that we use consistently within our projects. These “developer” plugins are not plug and play. Instead, they are plug, add remaining code to the plugin’s core code, and then play. We do this to save our client’s time and money, while also enforcing code uniformity measures within our projects across our entire WordPress team.

While this does save our clients' money and helps us get projects out the door faster, we do it for a more selfish reason – consistency. Our development team follows a very uniform development philosophy that basically states that if I built it, you should be able to jump in my code the first time and know exactly where everything is and how it works with everything else and vice versa. This makes our projects consistent and easier to maintain in the future.

That said, if you aren’t a developer and you’re reading this, you’re probably thinking that I’m asking something unrealistic of you. How can you possibly build your site without a developer and without plugins? You can’t. In reality, you absolutely need to have an experienced WordPress developer help you with your WordPress project.

If you aren’t in a position to do that, and you have no choice but to use plugins, then I suggest you follow these simple rules.

1. Avoid plugins at all realistic costs. If you have another option, take it.
2. Do every bit of due diligence that you possibly can. It’s worth the time. Read articles, read forum posts, ask the plugin author questions and ask other developers questions – WordPress StackExchange is a great place for this, but keep in mind, you never know who’s going to answer, so do your due diligence on the person that answered your question as well.
3. If you are adding plugins, consider your project more of a proof of concept than your finished product. Once your project gets traction, hire a professional WordPress developer (preferably a team) immediately. The last thing you want is to get some traction and have it all crumble because you didn’t make that move from functional proof of concept to finished product fast enough.
4. Go reread #1 again. Yes it’s that important.

In Closing

I know that this article sounds a bit like hate mongering towardsWordPress plugins, but really, it isn’t. When I was first starting out, I used plugins like they were paying me to add them to my websites. I loved them. I loved them so much that I setup a WordPress sandbox install just to try out different plugins so I could see if I liked them enough to find a way to use them in a project I was working on – even if they weren’t needed.

I just loved being able to add new features with the click of a mouse. When I started doing WordPress development, I started writing plugins and sharing them with people. I even did some free beta and bug testing for other people’s WordPress plugins. It wasn’t until right before I started working at the agency level that I realized all of the potential downfalls of “just grabbing a plugin.”

I’ve seen countless WordPress sites get hacked by malware, completely break, destroy a database, and more. So, while I understand that you might want to reach for that plugin, I encourage you to find another way when you have the means. Again, they aren’t all bad, but it’s a really bad day when you find out that you have a bad plugin installed in your website.

Lastly, to all the plugin developers reading this that are already mentally composing their hate mail to me, I encourage you to push yourselves to always create new and awesome things. I encourage you to change the WordPress plugin ecosystem for the better by keeping all of these things in mind while you create your awesome plugins.

I have a lot of respect for all of you, but the water is tainted and I feel that it’s important to share this reality with consumers. In the end, for those of you that are already adhering to similar ideologies, I thank you for pushing the WordPress plugin ecosystem into a better place.