What Are Must Use Plugins in WordPress? The plugin system is one of the most powerful aspects of WordPress. The ability to extend the functionality of the CMS quickly and easily is unparalleled in other platforms. Plugins are typically installed and maintained through the WordPress administration interface, and end up in /wp-content/plugins/ in their own folder. There’s an entirely different kind of plugin that exists though, and it’s called a Must Use plugin.
In this post we’re going to take a look at what they are and how they work, as well as, pros and cons of using them.
What Makes Them Different?
Standard plugins are stored in /wp-content/plugins/ but Must Use plugins are stored in /wp-content/mu-plugins/. The “mu” stands for Must Use, but it didn’t always. There was a time when it stood for Multi-User plugins, and was related to what we now call WordPress Multisite. This means that if you do some Googling, you might find some documentation that talks about Multi-User plugins. That’s very old, and you shouldn’t use it.
Something else that makes them different is how they’re managed. There isn’t a web UI for them like regular plugins, they have to be managed via FTP.
Another difference is that they’re always on. This is why they’re called Must Use. If they’re in the mu-plugins folder, they’re running. There’s no way to turn them off.
One more difference is that they’re almost always simple, single-file plugins, rather than folders filled with files like a regular plugin. This is because plugins in folders don’t work in mu-plugins unless you create a “calling” file in the main mu-plugins folder that includes the main file of the plugin in the folder.
That file might look something like this:
<?php // mu-plugins/load.php
You could have a separate file for each folder, or you could have a single file that calls them all.
How Are They The Same?
Structurally mu-plugins are identical to regular plugins. The header at the top of the main file is exactly the same. So if you already have a single file plugin in /plugins/, you can move it to mu-plugins and it will continue to work just fine.
Even with a plugin in a folder, where you have to have a calling file, aside from that the plugin is identical. You could take any regular plugin from the WordPress.org repository and put it in mu-plugins, create a calling file that simply uses the PHP include method to include the main file and it would work without editing.
Why Would Anyone Use A Must Use Plugin? (A.K.A. The “Pros” Section)
Must Use Plugins are difficult to meddle with. They can’t be turned off, so a client is less likely to “accidentally” deactivate them. They can’t be deleted in the WordPress admin area, so again, a client is very unlikely to remove the plugin altogether.
They can’t be updated via the admin UI, which we’ll talk about again in the Cons section. But it’s also a pro for the same reason as above. A client is unlikely to update a plugin that you’re not ready to have updated yet.
It’s very common for mu-plugins to be custom code, written just for one site. This means that there isn’t really an update mechanism out there. There’s no plugin server that it was downloaded from that could serve an update, so it simply moves it out of the way of the regular plugins.
Similarly, simple, single file, single function plugins are easier to manage and understand. A good Must Use plugin is so simple that you can look at the file name and pretty much understand everything the plugin does.
Here are some good example file names. See if you can guess what the plugin does.
See how that works? Each file does one thing and has minimal code.
One last reason someone might take code and make a Must Use plugin out of it is if the code is actually a library of helper code. Extended Custom Post Types by John Blackbourn isn’t actually a plugin at all. You could include it in your own plugin as a library, or you can put the folder in mu-plugins, create a caller file, and the library would magically become available to all other plugins and themes.
CMB2 is another plugin that serves as a library. This one actually is a regular plugin, which you can install in WordPress, but you can ALSO treat it like a real library, put it in mu-plugins, and create a caller file for it.
Why Would Anyone NOT Use A Must Use Plugin? (A.K.A. The “Cons” Section)
I mentioned above that Must Use plugins cannot be updated via the WordPress admin. This means that if you do put a regular plugin in mu-plugins, and an update becomes available, WordPress will neither tell you about it, nor give you a mechanism for updating it. You’ll need to keep an eye on the news feed for that plugin, and then manually upload a new version when it’s ready.
All things considered, Must Use plugins are much more difficult to manage.
The Roundup: When To Use Them And When Not To
You should use a Must Use plugin when:
- You wrote the plugin, and manual anticipates aren’t an issue.
- The code is a library where you need stability, and updates should be very closely controlled.
- The site absolutely depends on the plugin being active, and it should never ever be turned off.
You should NOT use a Must Use plugin when:
- The code is maintained by someone else (perhaps it comes from WordPress.org, or a commercial plugin shop).
- The codebase is larger than one file, and needs to be a folder.
- You might need to easily turn the plugin off and on for any given reason.
Must Use plugins are neither better nor worse than regular plugins; they’re simply different tools with a different purpose. The trick is looking at the function and business case for the plugin and deciding if it should be installed as a regular plugin or as a Must Use plugin. Experience will help you understand that, but you can always ask someone who’s used them before, someone from your local meetup, or even the OSTraining support forums, or the WordPress.org support forums. Once you get the balance worked out, Must Use plugins are exceptionally useful.