Guide to Plugins and How I Decide To Use Them

In the WordPress world, plugins are an essential part of the ecosystem. Plugins are add-ons to WordPress sites created by outside users to add capabilities to a base WordPress theme. This can be something as small as reordering blog posts to implementing an entire e-commerce interface. Depending on the approach, every WordPress build will have a different level of reliance on plugins.

Throughout my career, I have managed, built, maintained, and audited a large sample of WordPress sites. And plugins vary quite a bit from site to site (both in positive and negative ways). When I am building WordPress sites, I take a very conservative approach in whether I use a plugin in the first place and then which plugin I decide to use. In this post I will discuss:

When I will actually USE plugins

Introducing plugins into a custom build is not a decision I make flippantly. At the end of the day, plugins are additional code that get added to a website in order to achieve a certain functionality. And with that code coming from a third-party, the decision becomes dependent on trust, reliability, and compatibility. It is no different than buying any product.

The approach I take with plugins is “I don’t need them until it is proven that I do”. At baseline, without knowing the situation and context, I will always try to start with a custom solution. This is the best way to keep your site light and secure. In general, if I am using a plugin, it is usually after I have exhausted all the different custom build avenues. That being said, there are some situations where using a plugin ends up being the route I take.

Budget/Time Constraints

The time and budget, or lack thereof, is the number one reason I will opt for plugin over a custom solution. And it is very common for developers to use plugins as a time-saving measure during their builds. Most every WordPress feature can be built custom and without a plugin, but building it custom ostensibly takes longer. And for me personally, time, specifically working on a tight deadline, more than budget will usually be my main factor is whether I use a plugin. I do my best not to let how much I am making on a project affect my decision-making process.

Specific Client Request

It isn’t uncommon for a client to want a specific plugin used on a website or build. And for the most part, I am amenable to the request if the preference is borne out of the good technical reasons. Sometimes there is a level of comfort with a certain workflow or interface that the client and their team is already used to. If that is the case, once I get an understanding of what those things are, it isn’t uncommon that the parts they like about the plugin can be recreated in a lighter more efficient way. The other reason I encounter is that a plugin has a pre-existing integration with another third-party software they are using. In this scenario, I will leave the plugin in place, but may pitch moving away from it in a separate project/scope.

Legacy Build/Plugin Add-on

Sometimes, there are situations when a site is being rebuilt, either from another WordPress site or a non-WordPress platform. In the case of refreshing a current WordPress site, a very common task is migrating plugin specific content (like events, entries, etc). In this case, using the same plugin in lieu of building out a new interface and spending time migrating the content over sometimes is the more prudent way to go. 

There are also cases where plugins like WooCommerce or Gravity Forms are already setup on a site. In this case, sometimes it is easier to use an add-on from the same plugin provider since there is already infrastructure there. Usually in these cases, writing custom code will require rebuilding many parts of the site and isn’t an efficient use of time.

What do I look for in Plugins?

Now, if we get to the point where we need to use a plugin, it is important to be deliberate about which plugin is used. Every build, scope, specs, etc. are going to be different, so the list of factors provided in this section are not going to be 100% prescriptive. However, they are broad to where the characteristics are going to be true for most plugins.

Number of Users and Reviews

The first thing that I am usually looking at before anything else is the number of users, and to a lesser extent reviews. It doesn’t make or break my decision, but this is kind of a greens fee for a plugin to be considered. If the code and functionality on a plugin is immaculate, but only has 500 users, there is a good chance I am going to pass. 

Don’t hear what I am not saying – number of users is not necessarily an indicator of plugin quality. However, it does tell you that the plugin has been stress-tested to an extent. Usually with high user counts comes bugs, tweaks, updates, and such to accommodate the user base. As far as number of users, there is no hard and fast rule, but I feel fine if I see at least 5,000 users. I feel even better and more secure if I see a number higher than 10,000. The LOWEST user count I would usually entertain is 3,000.

While I personally like to just test a plugin to build my own experience, I do like to peruse the reviews of the plugin. The star rating is fine, but usually the actual written reviews tend to be far more insightful as to the overall plugin experience. What I usually hope to see is developers commenting on their experience with customizations. And if there are non-technicals, I’m hoping to find comments around ease of use.

Documentation

Okay, the plugin has a high user base and decent to great reviews. The next thing I look for is documentation. This is basically the instruction manual for the plugin. The amount of documentation varies from plugin to plugin, but the more it has, the better. It will sometimes be on the plugin website in its own dedicated section, which is preferable. Other times, it can be in a file on the plugin’s GitHub. 

Whatever the form, documentation is key, especially for long term use of the plugin. The more documentation, usually the better chance the plugin will be able to handle the current request and any future ones as well.

Custom Hooks and Filters

Within the plugin’s documentation or GitHub, I am looking to see if they have custom filters or hooks. Filters and hooks refer to functions that can tap into the plugin capabilities and be customized. With that, developers can leverage a very high level of customizations. This is great not only for delivering to the client what is needed, but also ensures that proper adjustments can be made to maintain compatibility with your theme. 

Overall, documentation is important for technical know-how and instruction. What it really shows is that there is a certain level of care and quality control that has been put into the building of the plugin. And therefore a higher level of confidence.

Latest Update/Release Notes

Speaking of care and quality control, the next aspect I look at is the last update of the plugin and the release notes. I usually like seeing that the plugin is being updated at minimum monthly. Updates to plugins are things that the plugin creators are doing to ensure the plugin is getting better and staying secure. This can be things like a security patch, a new features, and code cleanup. 

At the very least, seeing a relatively recent update from a plugin tells you that a plugin is actually being managed. Remember, when you decide to bring a plugin into your theme, you are introducing 3rd party code. This basically makes your theme/website a group project. And like any good group project, you want to make sure the other members are doing THEIR part to keep the plugin in tip top shape. 

And this is where the Release Notes come in. Usually, the release notes can be found either on the plugin website or on the plugin’s WordPress marketplace page. The release notes provide the written explanations of what is being done during each update. It will usually be quick notes like “fixed bug from version 2.1” or “security patch from PHP update”. The contents don’t matter too much to me as much as the general existence and regular frequency of them. 

Admin Experience

This aspect is completely my personal preference. It isn’t a formal best practice, but is more of what I like in a plugin. For me, I am very turned off by a plugin if it has a convoluted admin experience. Too many sections, non-intuitive editing, incomplete instructions – all things that get on my nerves. Usually, I am able to navigate it just fine, but I am a developer who deals with these technical things on a regular basis. For me, I hate for the admin experience to be tedious for something as simple as say changing text or colors. Again, this is completely personal. A plugin can work just fine and perfectly even without a good admin experience, but to me the admin experience is just as much part of my plugin assessment as what it does on the front-end.

But what about code bloat? And plugin size?

One thing that is not mentioned in my list of criteria is code bloat/plugin size. This is very important, however, full transparency, I am not really looking at it and I don’t check the size when I install it. Now, if I see the site is being slowed down, I will investigate further, but it is not explicitly part of my decision making process.

The main reason is that I don’t use plugins too often. As it is, I am very conservative on whether I use plugins in the first place. If a site had a lot of plugins to begin with I would care more. Additionally, if I get to the point where I need a plugin, I’m usually in a position where I care a lot more about the functionality working properly, so code bloat because of a secondary, maybe even tertiary, concern. 

TL;DR (written by AI)