What do you do when you want your WordPress project to do something new?
What do you do when your project needs forms, spam abatement tech, performance tweaks, fancy galleries or slideshows or other visual candy, e-commerce, marketing automation, help desk, digitally signed documents, mobile apps, SEO tuning, or extra security?
What do you do when your project develops a need you couldn’t even have envisioned when the project was initiated?
WordPress can do a great deal out of the box, but it can’t do everything. That’s good, of course, because if it could do everything, the engineering feat required to achieve such capabilities would make WordPress expensive instead of free. And ridiculously complex instead of user-friendly and simple. And a horrible performer instead of nimble and efficient. And abandoned. You get the picture.
So, instead of trying to do everything, WordPress smartly bundles the most important capabilities that the majority of projects are likely to need, and wraps them in an extensible environment that allows you to add functionality as required.
Options for extending your capabilities
You have two options for adding capabilities to your project:
- Plugins are packages that add functionality or behavior to a site. In the vast majority of cases, when you change your theme, your plugins will not be affected. The behaviors and settings they have added to your site will remain available to you as they were with your previous theme. There are several different types of plugins, and many different ways of categorizing them. However, for the purposes of this discussion, it’s helpful to think of plugins in two big buckets:
- Free plugins are exactly what you’d expect: Freely available plugins that you can install in your project to add the behavior you need. The main source for free plugins, is WordPress’ own Plugins Repository, which includes about 55,000 plugins at the time of this writing. There are many more free plugins to be found on GitHub and elsewhere.
- Premium plugins are paid products that generally come with support and expanded feature sets. Some premium plugins are actually expanded versions of free plugins, while others have no free versions.
- Custom code. You (or your team) can write code that “talks” to WordPress and adds functionality that is tailor-made for your project. This code will take one of two forms:
- Theme code (often in a special file called
functions.php, or another file that is called from
functions.php). This code should primarily affect look-and-feel, and include only features that you don’t mind losing (or reimplementing) if and when your project adopts a new theme.
- Custom plugin. This is the way to go with code that adds functionality that transcends “mere” look-and-feel. Again, capabilities created with this code (plugin code) remain available to the project even if and when the project does adopt a new theme (for a new look-and-feel).
- Theme code (often in a special file called
Since the topic of this article is canned plugins vs custom code for adding new functionality to your project, I should point out that the choice is generally not applicable to the more complex plugins (e-commerce, performance or security workhorses, etc). This is because the choice between custom code or a third party plugin as extensive as WooCommerce, for example, is simply not practical. WooCommerce is an e-commerce plugin that is extremely complex and expensive to emulate. Choosing to implement your own e-commerce rather than using an existing canned plugin is unlikely to be appropriate for anything but the rarest cases. The canned plugin approach (WooCommerce in the current example) is far more cost effective for projects that need such functionality than most alternatives you can build in-house.
This discussion, then, is about choosing between plugins of relatively limited scope on the one hand, and custom code on the other.
Option 1: plugin
There are advantages and disadvantages to solving new capability challenges with plugins written by third parties:
- Installing a plugin is almost always faster than building a custom solution.
- Plugins from reputable sources are carefully vetted and maintained, which means that you are getting Quality Assurance support (QA) in addition to the functionality your project needs. This is especially true for plugins from WordPress’ Plugins Repository.
- Plugin administration is very easy, so if you have to replace one plugin with a newer or more stable alternative, you have a well documented and supported process at the ready.
- Well made and supported plugins are adapted over time to respond to changes in WordPress itself, to new security threats online, to emerging opportunities with which a plugin can assist, and more.
- Well made and supported plugins are documented so you don’t have to commit more process to memory or struggle to document yet another dependency in your project.
- Plugins are easy to deactivate when troubleshooting website issues (some troubleshooting processes require us to deactivate plugins as we attempt to isolate root causes).
- Lesser levels of skill are required for managing plugins that for authoring code.
- Well maintained WordPress projects can easily host a very large number of plugins (there is no real limit). However, every plugin does add complexity that is inherently watch-worthy, in that it must play well with all other plugins. This form of complexity, which is essentially about inter-component compatibility, can make stability of the project overall rather challenging.
- Plugins intended for general distribution tend to be more complex than is strictly required for any one project. This is because authors are attempting to service the needs of many different types of projects, under a potentially wide array of configuration circumstances, so their code needs to account for a longer list of implementation scenarios. To account for these many possibilities, their plugins need to be more robust, and therefore more complex than would be the case if they were designed to service a single project or implementation scenario.
- Vetted and maintained plugins, even from the most reputable sources, sometimes degrade. Sometimes developers move on. Sometimes changes in WordPress itself cause problems in plugins that worked quite nicely in past versions of the platform. Whatever the cause, some plugins simply drop in quality over time, and this is quite a bit more likely in the limited scope plugins we’re considering here, than in the ecosystem influencers that are backed by serious budgets and community-wide commitments. Once support for a plugin begins to wane, behavior cannot be expected to evolve as required to match changes in the platform, documentation becomes less reliable, and even core site functionality may be threatened.
Option 2: custom code
Much like the plugin option, the custom code option comes with certain advantages and disadvantages:
- Administration of features enabled by custom code can be made even more intuitive than a publicly available plugin because the entire user experience it creates can be fully customized to the needs of the project and its users.
- Custom code can evolve with the rest of the project without concern for compatibility with other projects, as there are no other users to consider while evolving and maturing features.
- If implemented as a custom plugin (such as a “Site Specific Plugin”), your custom code can be just as easy to disable during troubleshooting engagements as a publicly available plugin, and even more so (because it can be designed to be disabled with safeties that are very specific to your project’s concerns).
- If implemented as a custom plugin, your custom code can add relatively little complexity to the site overall, especially if this plugin bundles all of your required custom refinements in a single, well tested, and well balanced “Site Specific Plugin”.
- Plugin degradation over time, or feature drift that invalidates the plugin in your particular scenario (even when code quality remains good), or other weakened connections between the new code and the rest of your project, are less likely to happen in code that is made specifically for your project.
- Custom code is often harder to integrate into your project (unless it is smartly bundled as a plugin that is implemented with applicable best practices).
- The lesser distribution and lack of exposure to community scrutiny means that custom code won’t usually enjoy the same level of vetting and maintenance that a publicly available plugin enjoys.
- Greater levels of skill are required to implement and maintain custom code than is the case with installing plugins.
So, Custom code or plugin?
Given all of these advantages and disadvantages, how do you decide when to plugin and when to build? When is it proper to install yet another plugin for this little tweak or that? And when is it preferable to extend your project’s capabilities with custom built code?
My own preference is to decide by answering following questions:
- Is the candidate plugin merely offering a UI for native capabilities that are easily called with code that is well documented online?
For example, is the plugin essentially a UI for creating Custom Post Types? If so, is it also adding something to visitor UX that goes well beyond common implementation of
register_post_type()and related WordPress functions?
If all I’m getting from the plugin is functionality that I can easily write and maintain myself (as in the case of CPT’s), I’ll just code.
If, in addition to CPT functionality, I also get some tasty UI candy that includes JS libraries that I don’t have time to fully investigate and implement, I might still use the plugin.
- Is the candidate plugin simply injecting code into my templates that is unlikely to change frequently? Or ever?
For example, is the plugin adding code for a chat application that is rarely going to change? Or never change? Or is it also adding special instrumentation to further streamline some other aspect of this chat app?
If all I’m getting from the plugin is the service I could provide myself by simply opening a template file (or even a bunch of template files), I see no reason to add the plugin.
If, in addition to injecting this code, I also get tools that augment the chat experience, and if these tools are actually useful (not just the latest cool), I might still use the plugin. Maybe.
- Is the candidate plugin replaceable at the infrastructure layer of the site?
For example, is the plugin providing caching with unnecessary sophistication, and, as such, possibly replaceable by a micro-cache operating lower in the stack?
If all I’m getting from the plugin is the reminder in the admin that there is indeed caching in the system, but this caching includes intelligent expiries that this particular site simply doesn’t need, I’ll opt for the micro-cache.
If, in addition to caching, and even despite the unnecessary features, this plugin also provides cache-related stats that this project happens to need, I might still use the plugin. Sometimes.
- Is the candidate plugin providing access to data from external services that I can get elsewhere? Is this access clearly superior or particularly convenient despite alternative availability?
For example, is the plugin showing analytics data that I can just as easily see at the provider’s interface?
If all I’m getting from the plugin is the same data I get at the data provider site, and I’m already visiting the provider’s site all the time because I have several other projects that are also using this same provider, I’ll generally skip the plugin.
If, despite getting my data elsewhere, the stakeholders in this particular project really want access to the data in their own admin, I may use plugin after all, unless the provider enables me to send to them snapshots in email that easily suffice.
My bottom line is that I do look for ways to limit the number of plugins I use. This is not because I think there should be some sort of limit to the number of plugins in use on any given site. To date, every argument I have ever encountered about the maximum number of plugins we should use has been fairly meaningless. The WordPress Page Lifecycle is built so intelligently that it will allow the loading of very large numbers of plugins, as long as these plugins are well built and standards compliant. So why am I so interested in limiting the number? Maintenance.
Compatibility, interoperability, stability, etc, all come down to how easy and safe a site is to maintain. Fewer complex interactions with third party plugins translate to simpler and safer long term experiences.
Over to you
Do you have any rules for including or excluding plugins? Any processes in place for evaluating them over time and changing direction as required? Any nightmare experiences that inspired you to toughen your policies?