Install or develop?
It’s true. There is a plugin for pretty much everything in the WordPress universe. So let’s click our system together! Or should we?
I really like the plugin system of WordPress. And it is a great advantage that there is this wide range of available plugins. It is part of the foundation of why we can use WordPress for a simple blog site, but also for a complex website with lots of features. But I don’t like the “there’s a plugin for that” mentality that I sometimes encounter with developers.
With every installation of a third-party plugin, we build the future and success of our project on someone else’s shoulders and put a lot of code into our codebase that we don’t really know, but for which we are responsible in the end. But of course we don’t want to reinvent the wheel either, that’s why we chose an open source software like WordPress, right?
I regularly have to answer the question: Install or develop? In this article I would like to give some insights into my thought process.
There are a few no-brainer plugins like WooCommerce or whatever SEO plugin you chose to suite you best. But apart from that, here is what I always do.
tl;dr
function shouldInstallPlugin(
$plugin,
$features
){
// What are we talking about?
if(isEasyAndSmallImplementation($features)){
return false;
}
// Maintenance
if(isPoorlyMaintained($plugin)){
return false;
}
// Publicity
if(isBadRatedOrSupported($plugin)){
return false;
}
// Inspection
if(doesCodebaseSmell($plugin)
){
return false;
}
// Flexibility
if(isNotFlexibleEnough($plugin, $features)){
return false;
}
// The scope
if(
hasMuchLargerScope($plugin, $features)
&&
myImplementationCanHonestlyProvideTheSameQuality($plugin, $features)
){
return false;
}
// Stick to the core
if(canBeDoneWithCoreFeatures($plugin)){
return false;
}
// Compatible to development mode
if(doesNotFitMyDevelopmentMode($plugin)){
return false;
}
return true;
}What are we talking about?
Before I start researching a plugin, I should have a good understanding of what I want it to do. What is the exact scope of features I need to implement, and might be features I need to implement in the near future related to it. If it is for a client, I will need a detailed briefing.
If the goal is clear, I think about how I would implement it myself. If it’s just a handful of hooks or a few lines of code, I just do it! There is absolutely no point in installing a plugin for a few lines of code that I can implement myself without effort. On the other hand, if it’s not clear what an implementation would look like, or if I would have to maintain a lot of code, it is time to do some research!
if(isEasyAndSmallImplementation($features)){
return false;
}Maintenance
The very first thing I look at is the plugin’s up-to-dateness and maintenance. Does this plugin receive updates and compatibility checks for the latest WordPress version? How long has it been since the last update? Any plugin that is not checked for compatibility with the latest major version of WordPress must be rejected, in my opinion. Apart from that, there is no number of days or months for definitive rejection of the plugin, but I do get a sense of whether I can get support and updates if something goes wrong with future PHP or WordPress core updates.
if(isPoorlyMaintained($plugin)){
return false;
}Publicity
Of course, I have a look at the rating of plugin. How and why do users rate the plugin good or bad? How many ratings does this plugin have. And what support requests or problems are known. Does the maintainer answer support requests and how are the answers?
I also take a look at the number of installations of the plugin. If this number is very low, that could be a warning sign. But not necessarily. I just try to be aware of the size of the audience.
if(isBadRatedOrSupported($plugin)){
return false;
}Inspection
Next, I take a look at the code base, which means I install the plugin into the project or in some new WordPress installation. I don’t necessary always look at the code, but at the file and folder structure. Does it seem to have a structure that makes sense? Are there any files or functions that don’t seem to fit the use case of the plugin? Are there any weird things happening? How many files does the plugin have and does the number match the scope of the plugin? Is it compatible with the current php version? Does it produce php warnings? What about hooks and template?
Personally I like plugins with a narrow scope. It should only do one thing and that one thing very well. If there is something that stands out, I would dive deeper. If not, it’s worth a try.
if(doesCodebaseSmell($plugin)){
return false;
}Every time I update a plugin, I do a recheck. If you use a version control system like git that is very easy because it’s totally fine to only have a look at the changes.
Flexibility
A big issue with many plugins is that they are not flexible enough. If there is a UX and UI design that I have to implement, it’s most likely necessary that the plugin provides a way to change its data structure, behavior or HTML output in the frontend. But that very much depends on the use case, how much of flexibility the plugin needs to provide.
Filters & Actions
WordPress makes it pretty easy to provide custom plugin hooks, so please provide them and don’t be shy about it! Either there should be an up-to-date documentation page where I can read about the available hooks, or the plugins interface should be well documented in the code somehow.
Templates
You can do a lot with modern CSS. So it’s not always necessary, but I think it is good practise for a plugin to provide a way for theme creators to change its output. This is usually done via overwritable templates.
JavaScript
If there is an interactivity in the frontend, I bet it doesn’t behave exactly the way the client’s design wants it to. That’s why I take a look at the plugin’s registered asset files. What I like to see is if the API and the UI element were split into separate javascript files. That’s because then you can dequeue the javascript files responsible for the ui interaction and add your own interaction javascript but still use the provided javascript api for the plugin features.
if(isNotFlexibleEnough($plugin, $features)){
return false;
}The Scope
As I said already: I think plugins should have a small scope. They should do one thing, and that one thing well. They should also be extensible and provide filters for developers. If what I need from the plugin is only a very small part of what the plugin provides, I think twice about installing all the “dead code” and functionality. There is also the risk that this particular small feature of the plugin is a dead end and could be dropped in future plugin updates or simply not receive any updates or attention from the plugin authors.
When I realize that the plugin is much larger than my needs, I start to reconsider the idea of implementing it myself. At this point, I have more knowledge and usually have some ideas on how to implement the features, as I have inspected plugins that have already done this.
To be honest, I think this decision is the hardest of the whole process because I found a candidate that would save me a lot of work, seems to be popular in the community, has a nice codebase, and provides all the flexibility I need, but I have to worry about putting code into my project that I don’t actually actively use and might be a security risk, could slow down performance, or have other unforeseen side effects. So I need to give myself an honest answer about whether I can implement the features with similar quality and maintain the plugin in the future, and what the costs are now and in the future.
if(
hasMuchLargerScope($plugin, $features)
&&
myImplementationCanHonestlyProvideTheSameQuality($plugin, $features)
){
return false;
}Stick to the Core
Plugins should extend the WordPress core and not rebuild something that already exists and works fine.
For example, I think all the landing page editor plugins are obsolete with the release of Gutenberg. It’s not like I think Gutenberg does everything right, oh no, I definitely don’t think so. But it doesn’t seem to be a worse option than any of the others and it is already there. Unlike the classic editor, which offered pretty much no easy way to create landing pages.
if(canBeDoneWithCoreFeatures($plugin)){
return false;
}Compatible to development mode
I always have some kind of deployment where I put my code into a git repository and somehow a deployment is triggered to bring the changes on some stage or on the production environment. That’s why I generally don’t like some things to be handled by plugins but always try to put it in code. That would be all data structure what I would associate with the domain model. So I try to avoid plugins that provide a way to configure custom post types, custom taxonomies or meta fields and store this structure in the database. These are things that belong to the codebase and should be version controlled.
But that’s just me and one example of how development mode makes a strong argument against or for a plugin with a certain behavior. I would always check if what the plugin does is in line with my development mode.
if(doesNotFitMyDevelopmentMode($plugin)){
return false;
}Conclusion
Keep your codebase clean and don’t overdo it with the number of installed (third-party) plugins. But also take advantage of the rich plugin ecosystem WordPress has to offer.
I hope this was some help for your next decision on the question “install or develop?”… Maybe, it could, or no, or yes… It’s complicated, but doable.
Thanks for your time!
How do you decide to install or develop a plugin?
