Must-Use plugins in WordPress

Must-use plugins (mu-plugins) - mandatory plugins that are installed in a special /wp-content/mu-plugins folder. They are always active for the site and all sites of the network for multisite.

They can not be disabled through the admin panel. To disable them you have to delete plugin file from wp-content/mu-plugins directory.

WordPress automatically connects all php files from /wp-content/mu-plugins folder. Subfolders inside the mu-plugins folder are not checked. Connecting php files from subfolders must be prescribed manually, in the file which is located directly in the /mu-plugins folder.

mu-plugins are displayed in the top information line in the admin panel.

Changing the MU plugins directory

The MU Plugins directory can be changed. To do this, you need to define the WPMU_PLUGIN_DIR and WPMU_PLUGIN_URL constants in the wp-config.php file.

Pros and cons

Advantages of "necessary" plugins

Always enabled, no need to activate them in the admin panel. Users can't disable them, intentionally or accidentally.

Easy to plug in and activate, you just need to add the plugin file to the wp-content/mu-plugins directory.

Loaded at an early stage of WordPress loading - before the regular plugins. The files are connected in alphabetical order.

Disadvantages of "necessary" plugins

There is no need to use mu-plugins in most cases because regular plugins are more convenient.

  • Not checked for updates, which means that when a new version of a plugin appears, we won't see a notification about it. Therefore, it is necessary to keep track of the appearance of a new version on your own;

  • Hooks for activating/deactivating the plug-in do not work, which are responsible for events concerning plug-in installation or removal. Therefore, when activating, you have to add tables or options to the database and do other things, and when deactivating, you have to delete everything associated with the plugin from the database and files yourself.

  • WordPress searches for php files in the my-plugin directory and does it in an other way than for normal plugins - it doesn't look through the files inside the subfolders. In this case, you will need to create a boot file in the my-plugin directory, so that it connects files from subdirectories, like this:

    // mu-plugins/load.php
    require WPMU_PLUGIN_DIR .'/my-plugin/my-plugin.php';

When is it useful to use mu-plugins?

In cases when it is more convenient than a regular plugin... I, for example, recently put code in the form of such a plugin to set up 301 redirects from old URLs when I was changing the friendly-URLs on a long-established site. It seemed like the best solution to me, because:

  • inserting such a redirect into the theme is wrong - what if the theme gets changed and all redirects disappear.

  • if install as a regular plugin, then if you accidentally turn it off, all the redirects will disappear, you might not catch it.

How does it work?

MU plugins loads earlier than normal plugins. Let's take a look at the WordPress loading scheme. Here I'll mention an interesting picture (I liked it a lot):

WordPress loading scheme

As for the code, how exactly the files are plugged in. See the code snippet responsible for the MU plugins, from the theme wp-settings.php file:

// Load must-use plugins.
foreach ( wp_get_mu_plugins() as $mu_plugin ) {
	include_once $mu_plugin;

	 * Fires once a single must-use plugin has loaded.
	 * @since 5.1.0
	 * @param string $mu_plugin Full path to the plugin's main file.
	do_action( 'mu_plugin_loaded', $mu_plugin );
unset( $mu_plugin );

Code of wp_get_mu_plugins():

function wp_get_mu_plugins() {

	$mu_plugins = array();

	if ( !is_dir( WPMU_PLUGIN_DIR )
		return $mu_plugins;

	if ( ! $dh = opendir( WPMU_PLUGIN_DIR )
		return $mu_plugins;

	while ( ( $plugin = readdir( $dh ) ) !== false ) {
		if ( substr( $plugin, -4 ) == '.php' )
			$mu_plugins[] = WPMU_PLUGIN_DIR . '/' . $plugin;

	closedir( $dh );
	sort( $mu_plugins );

	return $mu_plugins;

As we can see, the WPMU_PLUGIN_DIR directory is checked to make sure it exists. If it exists, all .php files are collected from it, sorted alphabetically (ascending) and are connected one by one.

History of Must-Use plugins

The "mu-plugins" directory was originally created for WPMU (Multi-User) network plugins, to allow administrators to activate plugins for an entire network of sites or blogs. At that time, this feature was necessary, because of the specifics of the Multisite build: administrators could not activate plugins for the entire network from the admin panel. With version 2.8 it became possible.

The code responsible for multi-user-plugins (mu-plugins), was moved to the main WordPress code. And shortly before that, the code base wpmu was merged with the main WordPress build, and all sites, regardless of build, got the ability to automatically load plugins, and it did not matter if it was a simple WP or WP-Multisite. This feature is more convenient for all kinds of installations of WordPress and for different situations related to the creation of the site.

As a result of this change, the name "mu-plugins" is no longer true, because mu-plugins now worked for regular builds as well. The "mu" prefix no longer meant that the feature belonged to the multi-user build. Despite this, they decided to keep the name, but interpret it differently "Must-use plugins". That is, these are must-use plugins - plugins that should always be used. They work for all sites and do not depend on plugins in the admin panel.

PHP was something similar: PHP used to stand for "Personal Home Page", but was later re-interpreted as "PHP Hypertext Preprocessor" and, in the spirit of hacker tradition, became a recursive acronym.

Acronym is a type of abbreviation. It is a word, which is an abbreviation that can be pronounced together as ordinary word, unlike other types of abbreviations, which are pronounced "by letters", for example: NASA.

Recursive acronym - acronym that refers to itself.

It has become traditional among computer guys to choose acronyms that indirectly or directly refer to themselves. One of the earliest examples is TINT, which appeared in 1977: "TINT Is Not TECO" ("TINT Is Not TECO").