I’ve found using this directory an indispensable way for organizing my installs, maintaining separation of theme (display) functionality from site functionality, and adding more one level of insurance a less-technical user can’t accidentally break or disrupt the operation of the site.
When I first started using the mu-plugins directory on my WordPress projects, I mainly used it to house my must-use plugins that the site required in order to function properly. I did this mainly to ensure my clients wouldn’t accidentally deactivate or (worse) delete a plugin and inadvertently break their site. So in went various meta boxes, custom post types, and custom taxonomies.
In talking with other developers I was asked, why not just stick those in the theme’s
functions.php file? The short answer, the sites I work on tend to be internal sites for large corporations who frequently change their theme up. Housing site-dependent files in the functions.php file is just asking for trouble. A theme’s
functions.php file should only house functions that are specific to that theme. I’m a big believer in function separation/organization. Yes, you can house functionality in a theme, but I personally think any functionality that does not directly relate to the appearance of the site’s content should be deployed by a plugin.
There is a common misconception among WordPress devs and users that too many plugins will slow a site down. Only poorly-developed plugins will slow your site down. Plugin development tends to take a backseat to Theme development in the WordPress community. Maybe it’s because it seems more daunting since it’s a bit more technical than themes in that it’s more php and action/filter hooks rather than HTML and CSS. Or maybe it’s because Themes are much more tangible; you can visually see your changes to your Themes, whereas adding an id attribute to the
body element is hidden under the hood.
Tangent. Back on track.
So a good way to extract functionality (that your site needs in order to work properly) out of your theme, but still ensure its use, is the
mu-plugins directory. If you haven’t heard of it before, not to worry, a lot of people in the WP community haven’t. It’s not even created in a standard install of WordPress, you have to manually add it in your
wp-content directory. It goes in the same level as your
themes directories, like so:
/wp-content/mu-plugins /wp-content/plugins /wp-content/themes
Some of the cool benefits of this directory are:
- You don’t need to activate them, they run automatically.
- Your other plugins can use hooks in your mu plugins since they load before normal plugins.
- Your admin users and clients can’t accidentally turn off functionality that’s needed to run your site.
Some downsides (though I don’t really consider these downsides):
- They can’t be turned off on the plugin screen in the back end. (Though they are listed there.)
- They don’t show update notifications.
- They don’t trigger activation hooks (since they aren’t activated or deactivated).
- WordPress doesn’t check nested directories within the MU directory.
I won’t go into too detailed of an overview in this post, but you can find a detailed description in the Codex here: Must Use Plugins. In it’s most basic use, you can upload single-level plugins (i.e., one file) to this directory, and WordPress will automatically enable it during execution. In fact, WordPress will automatically execute any PHP code it finds in this directory, so be careful what you upload.
In addition to using this directory to house my files for custom post types, taxonomies, and metaboxes, I also use it to house libraries of individual functions that the site would/could use regardless of which theme is installed. (The body element id function listed above being one of them). I do this by using a master site file I call “siteconfig.php”. I’ll cover that in another post, but you can think of it similar to a theme’s
In some upcoming posts I’ll cover the following topics:
- Loading a
- Loading nested plugins (to keep this directory organized).
- Loading site-wide styles and scripts.