Nearly every WordPress site can benefit from some custom programming. Code that tweaks things a little, usually using hooks (actions and filters) to adapt the output or how certain things function. These type of small changes are usually best organized in a “site plugin”, that is a custom plugin built for your specific website. This is done instead of the other more common “solution”, stuffing any custom code changes into the theme functions.php. Now there is a time and a place arguably, to use functions.php as a place to organize code. However theme stuffing as I tend to call it, is definitely over-used, and comes with many drawbacks.
At the very least you should ask yourself (as a developer) is the change I’m making really a presentation (theme layer) change? If not, use a site plugin. Even in cases where the change does affect the presentation, bear in mind if it involves any substantial logic it may not really be suited for the theme layer. You could make the argument for instance that a custom menu walker used to render the output of WordPress menu’s differently, is a presentation change. That’s true to some extent, however, that logic can be applied to almost anything that changes what you see in a web page, or template. The reason a custom menu walker would be better placed in a site plugin is because it may require future changes, and it’s a fairly substantial amount of code. A walker class can be several hundred lines. It is a PHP class, which should be your first clue that it belongs in a plugin.
As a site owner if you’re reading this and not sure when/where site plugins would help, that’s okay. My advice is aim to work with developers who have plugin build capabilities, rather than those who only work at the theme layer. You’ll get a lot more mileage from your developers in terms of extending and integrating plugins and API’s, and the benefit of keeping your custom code better organized.
Better organization of code isn’t just for a developers benefit. It has a direct impact on the cost and effectiveness of development. Site’s with a lot of theme stuffing can be very difficult to work on, time is lost sifting through poorly organized code. A well organized and commented site plugin can be structured to make finding custom code a lot faster, and that should translate into lower development costs.
A custom site plugin should not be the end all be all solution however, otherwise you may run into the same problems as in using functions.php. Although it’s fine to organize many smaller changes into a single plugin, it’s important to know when to create a second custom plugin (or 3rd or 4th) for specific site features. Don’t continue to expand the scope of your “catch all” site plugin which is there mainly as a utility plugin. If for instance you had an ecommerce site with a number of WooCommerce customizations, those should fit well into your site plugin. However if you have extensive subscriber management customization involving WooCommerce Subscribers, this is an area that probably deserves a second custom plugin to isolate that codebase.
Site naming conventions for site plugins should be kept simple and easy to understand. If the site name domain is “cancun-dental.com” use the domain name and make the site custom plugin name “cancun-dental”. Easy peasy. Now if you have need for more custom site plugins consider adding to that name such as for the example WooCommerce Subscriptions customizations, the plugin name would be “cancun-dental-subscriptions”.