WordPress Must-Use Plugins: MU Plugins vs. Regular Plugins

WordPress has supported must-use plugins for years, but many administrators and developers never encounter them. They are not installed through the usual Plugins screen, they do not need to be activated, and they cannot be deactivated from the standard plugin controls.

That makes an MU plugin useful for code that is part of the site's operating foundation rather than an optional feature.

What Is an MU Plugin?

An MU plugin is a PHP plugin that WordPress automatically loads from its must-use plugin directory:

wp-content/mu-plugins/

A regular plugin normally lives in:

wp-content/plugins/

WordPress loads PHP files located directly inside mu-plugins on every WordPress request. No administrator has to activate them. In the dashboard, they appear in a separate Must-Use section on the Plugins screen, without the usual Activate or Deactivate controls.

MU means must-use: WordPress treats the plugin as required code whenever the file is present in the must-use directory.

MU Plugins Compared with Regular Plugins

The main differences affect activation, loading, maintenance, and directory structure.

A regular plugin is usually the right default. An MU plugin is appropriate when the code must remain active and someone disabling it could break site management, security policy, environment configuration, or another required service.

MU Plugins Load Before Regular Plugins

WordPress loads must-use plugins before network-activated and ordinary active plugins. It sorts the PHP files in the root of mu-plugins alphabetically before including them.

This early position lets an MU plugin register filters and actions before normal plugins initialize. It does not let the MU plugin override every later callback automatically. WordPress hook priorities and the timing of each callback still apply.

If MU plugins depend on one another, descriptive numbered filenames can make the order explicit:

wp-content/mu-plugins/
├── 00-site-bootstrap.php
├── 10-security-policy.php
└── 20-logging.php

Use ordering sparingly. Hidden dependencies between files make infrastructure harder to understand and test.

MU Plugins Are Not the Same as Network-Activated Plugins

The old Multi-User name causes understandable confusion. An MU plugin works on both single-site WordPress and Multisite. It does not require a Multisite network.

A network-activated plugin is still a regular plugin stored under wp-content/plugins/. A network administrator activates it across every site in a Multisite network, and WordPress keeps its normal plugin lifecycle and update behavior.

An MU plugin is different. WordPress loads it because its file is in wp-content/mu-plugins, regardless of whether Multisite is enabled.

A Minimal MU Plugin

If the mu-plugins directory does not exist, create it under wp-content. Then add a PHP file directly inside it:

<?php
/**
 * Plugin Name: Example Site Policy
 * Description: Demonstrates a small must-use plugin.
 */

add_filter(
    'admin_footer_text',
    static function ( $text ) {
        return $text . ' | Site policy code is active.';
    }
);

Save the file as:

wp-content/mu-plugins/example-site-policy.php

Reload the dashboard and open Plugins, then Must-Use. The plugin should appear there automatically. The example changes the dashboard footer only; removing the file removes the behavior.

The plugin header is not required for execution, but it gives WordPress a readable name and description for the Must-Use list.

How to Use a Plugin Subdirectory

WordPress does not recursively scan subdirectories under mu-plugins. This structure alone will not load example-core.php:

wp-content/mu-plugins/
└── example-core/
    ├── example-core.php
    ├── includes/
    └── assets/

Keep the full plugin in its subdirectory and add a small loader directly inside the root MU directory:

<?php
/**
 * Plugin Name: Example Core Loader
 */

require_once WPMU_PLUGIN_DIR . '/example-core/example-core.php';

Save the loader as:

wp-content/mu-plugins/example-core-loader.php

The loader is the file WordPress discovers. It then includes the main file from the subdirectory. This pattern preserves a normal project structure for classes, assets, tests, and dependencies.

Good Uses for MU Plugins

MU plugins are strongest when they contain site-owned or platform-owned infrastructure with a clear maintenance process. Common uses include:

• Applying an automatic-update policy.
• Defining environment-specific behavior for development, staging, or production.
• Adding required logging, monitoring, or audit integrations.
• Enforcing security restrictions that administrators should not casually disable.
• Registering organization-wide hooks on a managed WordPress platform.
• Loading a site-management framework or compatibility layer.
• Preventing an essential integration from being deactivated accidentally.

Web hosts also use MU plugins for hosting-specific services whose absence could impair a site. WordPress's must-use plugin documentation describes this as a common use case.

When a Regular Plugin Is Better

Use a regular plugin when administrators should be able to choose whether the feature is active, when the plugin depends on the standard installation lifecycle, or when it relies on WordPress's normal update experience.

Typical examples include contact forms, SEO tools, ecommerce extensions, editors, galleries, and other replaceable site features. These features may be important, but making them impossible to deactivate from the dashboard can complicate maintenance and troubleshooting.

Do not move an arbitrary plugin from plugins to mu-plugins and assume it will behave normally. Test it specifically as an MU plugin first.

Important Limitations

The same behavior that makes MU plugins dependable also creates operational responsibilities.

• No normal update notices: WordPress does not show the usual update status for MU plugins. You must own their update and security-review process.
• No automatic activation routine: register_activation_hook() does not run when a file is copied into mu-plugins. A plugin that creates database tables, options, roles, rewrite rules, or scheduled events during activation may be incomplete.
• No dashboard deactivation: troubleshooting requires renaming, moving, or removing the relevant file, or adding a deliberate environment-aware bypass in code.
• Root files only: a subdirectory needs a root-level loader.
• Early failures are serious: a PHP fatal error in required infrastructure can affect the entire site, including the dashboard and WP-CLI.

For database changes, use an idempotent versioned upgrade routine that can safely check and apply its schema when needed. Do not rely on an activation hook that will never run.

Operational Practices

Treat MU plugins like application infrastructure rather than forgotten snippets.

1. Keep the code in version control.
2. Give every root file a clear plugin header and purpose.
3. Test changes in development before production.
4. Maintain a documented update and security-review process.
5. Keep each responsibility small, or use a loader for a structured package.
6. Avoid dependencies on regular plugins unless failure behavior is explicit.
7. Make emergency recovery possible through server or deployment access.
8. Verify important behavior with both web requests and WP-CLI.

The inability to click Deactivate is not a substitute for monitoring, testing, ownership, or recovery planning.

Choosing Between the Two

The decision can usually be reduced to one question: is this an optional WordPress feature, or is it required infrastructure?

Use a regular plugin for functionality the site owner may enable, disable, replace, or update through the normal plugin workflow. Use an MU plugin for carefully maintained code that the platform requires on every request and that should not be disabled accidentally.

In short: a regular plugin is managed as a feature. An MU plugin is managed as part of the site's foundation.