Must-Use plugins. They’re convenient, they’re useful… and they can also be pretty darn scary.

Warnings, considerations, etc

DisableMU is not for every website. Many development houses, system admins, and hosting companies have very legitimate uses for /mu-plugins and have built business plans around utilizing this feature of WordPress. By installing and activating DisableMU on your website, you may break things. Please exercise caution and only utilize this plugin if you know what you are doing. As with most plugins, DisableMU is written with the intent of being helpful but you are responsible for its use or actions on your own website.

TL;DR

If your website shouldn’t be running any /mu-plugins, you don’t want arbitrary code running from the /mu-plugins directory. The DisableMU plugin acts as a safety net which ensures that WordPress cannot find the /mu-plugins directory, disabling that functionality.

Click here to get DisableMU from the WordPress Repository

History of /mu-plugins

In the beginning, it was difficult to manage plugins across multiple websites running under a single installation (“multi-user” sites, or “multisites”). To extend the standard plugin functionality, a new system of plugins was born which allowed site administrators to quickly and easily upload & enable plugins on all of their websites running in a multisite environment.

By uploading plugin code to /wp-content/mu-plugins/ rather than the standard /wp-content/plugins/ directory, you could instantly have a plugin up and running on all of your websites. No need to manually activate, no worries about any site administrators “accidentally” disabling those plugins. This is why today, as noted in the codex article itself, /mu-plugins is more commonly referred to as “must-use plugins” since when a plugin exists inside the directory, the system must use it.

How /mu-plugins work

The way that /mu-plugins are loaded is strange. These plugins are one of the first things loaded into WordPress on page load: in fact, the very first hook available in the WordPress load is “muplugins_loaded”… which is the moment in time directly after all /mu-plugins have been loaded. Also, these plugins are not allowed to live inside their own directories like “normal” plugins can. Administrators wishing to use /mu-plugins have to find drop-in plugins which run from a single initializing file, or potentially refactor common plugins to make them work inside of the /mu-plugins environment.

Nowadays, WordPress has better tools for managing your plugins across multisite installations right from the admin area, so the initial need for /mu-plugins has gone away. Managing items inside of /mu-plugins requires a much more hands-on approach since these plugins do not update along with “normal” plugins. In fact, they even display under their own filter on the primary WordPress plugins management screen which can make them easy to “miss” unless you know to look for them. The default “All plugins” filter does not truly mean “all”.

Possible security implications

So what’s the big deal? Well, the problem is that the /mu-plugin system is possibly the fastest, easiest, and most consistent way for arbitrary code to run on your website. If your website’s filesystem is ever compromised (and let’s be honest, this happens to more sites than we’d like to admit) it is already trivial for malware to create its own folders and scripts at the web root so it can be executed remotely. But having a dedicated location where you could place a properly-formed code snippet that executes every single time a site visitor accesses a script is a frightening prospect.

Site hacks are not the only way that code could suddenly run on your website, either. Each and every time you choose to install a new piece of software on your website, you are taking a chance on that theme or plugin’s author. Do we all look through every line of source code before installing something? Probably not. But what if, somewhere buried deep within the code, an author chose to drop some code that would add its own /mu-plugin code to your website when you activated the theme or plugin?

No website can or will ever be 100% secure, but DisableMU may give you just a little more peace of mind as a site administrator.

Using DisableMU to turn off /mu-plugins

Due to the nature of /mu-plugins and how they are written into WordPress core, there is no true way to “disable” or “turn off” /mu-plugins. However, WordPress is written in such a way that it will gracefully move on with life if it cannot find the defined /mu-plugins directory.

Since we are unable to apply any actions or filters to WordPress, we instead rely on writing constants to the wp-config.php file to accomplish what we need. There are three variables that are relevant:

• WPMU_PLUGIN_DIR
• WPMU_PLUGIN_URL
• MUPLUGINDIR

Upon activation, DisableMU will write these constants to the wp-config.php file and points WordPress at a random directory which does not exist. By doing so, WordPress will consistently fail to find the /mu-plugins folder path and not load any. When DisableMU is deactivated, it removes its content from the wp-config.php file.