I’ve been working on a small project, more of a web application than a site, that’s required the development of both a custom-theme and tightly coupled, but very specific functionality.

This is a very narrowly focused project (about which I’ll likely talk about at some point in the future) but in working on it, it’s forced me to get back into the theme development aspect of WordPress development a little bit.

No, I’m not doing any design – thankfully – but I am having to work on theme customizations from a functional perspective. In doing this, though, it’s had me revisit the required functions.php and some considerations I’ve never had before.

Furthermore, it’s caused me to look more deeply at the use of mu-plugins and ask when they are necessary and why I haven’t used them more in the past (or even when one would truly need to use them).

So I’m going to wax poetic about that a bit.

Functionality tied directly to the theme and WordPress core goes into functions.php. Domain-logic that required by the entire solution to work goes in a must-use plugin.

Functions and Must-Use Plugins

When I was doing theme development, functions.php was used for two things (which is problematic in and of itself) but still:

  1. to enable or disable features in themes,
  2. to define theme-specific functionality.

The Theme Developer Handbook reads:

The functions.php file is where you add unique features to your WordPress theme. It can be used to hook into the core functions of WordPress to make your theme more modular, extensible, and functional.

Theme Functions, Theme Developer Handbook

And I get it, but from my perspective and as WordPress has evolved I think that functions.php should be dedicated to theme-specific functionality in terms of things that hook directly into core such as:

  • customizer functionality,
  • menu functionality,
  • script and style registration,
  • and so on.

But if there’s anything that needs to run during one of the hooks and it’s more along the lines of domain-specific logic, then it does not belong in that file.

This raises a question, though: Where does domain-specific functionality reside?

Enter Must-Use Plugins

I know seeing things like inc directories are becoming more common, but I’m not concerned about those when talking about theme development especially when theme development is not my focus and that particular directory structure isn’t my style.

Anyway, when it comes to highly specialized solutions (where a solution is a combination of presentation and tightly focused functionality), I start thinking about mu-plugins.

And the reason I don’t think about a standard WordPress plugin is because they are generally designed to work with any theme and to add functionality. Not so with mu-plugins.

Must-use plugins (a.k.a. mu-plugins) are plugins installed in a special directory inside the content folder and which are automatically enabled on all sites in the installation.

Must-Use Plugins, WordPress.org

So here’s my thought process:

  1. Themes are for presentation
  2. Plugins are for functionality.
  3. Plugins are designed to be used regardless of a theme and across a breadth of a site.
  4. Must-Use Plugins are plugins that are enabled and in use by default
  5. Therefore, domain-specific logic for a specialized solution should reside in a must-use plugin.

Sure, a case can be made that some themes may require must-use functionality but does that not still fit with the idea that the functionality should reside in a must-use plugin?

Regardless, the approach that I’ve been following is this:

  1. Functionality that specifically associates theme features to WordPress core goes into functions.php.
  2. Functionality that’s domain-logic but requires the entire solution to work resides in an mu-plugin.

At this point in my career, I don’t do a lot of work that focusing on anything except the backend, but in the rare opportunities I have to expand the work I’m doing, I find that I’m still trying to be as analytical and thoughtful about the way I’m building the project.