- Article
- 3 minutes read
- Reviewed August 3, 2026
Must-use plugins, commonly called mu-plugins, are WordPress plugins placed in a special directory so they load automatically.
They are useful for infrastructure that administrators should not disable casually, but their loading and update behavior differs from ordinary plugins.
Where Must-Use Plugins Live
By default, WordPress looks in:
wp-content/mu-plugins/
PHP files placed directly in that directory are loaded automatically. They appear in a separate Must-Use section of the Plugins screen and do not have ordinary Activate or Deactivate controls.
How They Differ from Normal Plugins
Must-use plugins:
- Are enabled automatically.
- Cannot be disabled through the normal Plugins screen.
- Load before ordinary active plugins.
- Do not run normal activation hooks when added to the directory.
- Do not receive ordinary update notifications through the Plugins screen.
- Are removed or disabled by changing files on the server or deployment system.
These differences make them powerful but operationally demanding.
Subdirectories Need a Loader
WordPress normally scans only PHP files directly in the mu-plugins directory.
A project can place packages in subdirectories, but a loader file in the root must require those files. This is common in version-controlled deployments where each internal component has its own directory.
Appropriate Use Cases
Must-use plugins are suitable for code that is part of the platform rather than an optional feature.
Examples include:
- Hosting-provider infrastructure.
- Mandatory security or authentication integration.
- Environment configuration.
- Network-wide content rules.
- Deployment helpers.
- Shared organization-specific functionality.
- A loader for project modules managed through Composer.
When Not to Use Them
Do not place every plugin in mu-plugins merely to prevent deactivation.
Avoid the approach when:
- Administrators legitimately need to enable or disable the feature.
- The plugin depends on activation hooks for setup.
- Updates are expected through the normal WordPress interface.
- The team lacks a deployment and monitoring process.
- The code is a third-party plugin not designed for this loading model.
Activation and Installation Logic
Because activation hooks do not run, initialization must be handled differently.
A must-use plugin can check a stored schema version and run idempotent migrations during a safe initialization path. The process must avoid expensive work on every request and account for partial failures.
Updates Are Your Responsibility
WordPress does not provide normal update notices for mu-plugins.
Updates should be managed through:
- Version control and deployments.
- Composer or another dependency manager.
- Hosting platform tooling.
- An internal release process.
The team must track vulnerabilities and compatibility independently.
Load Order and Dependencies
Must-use plugins load before ordinary plugins, but relying on file-order assumptions inside the directory can be fragile.
Use explicit loaders, appropriate WordPress hooks and dependency checks. Code that needs another plugin should wait until that dependency is available rather than running too early.
Multisite History and Modern Use
The feature originated in the WordPress multi-user era, but it is available in normal WordPress installations as well as Multisite.
Today it is best understood as an infrastructure loading mechanism, not only a network feature.
Frequently Asked Questions
Can I deactivate a must-use plugin in wp-admin?
No. Remove or rename its file through the deployment or filesystem process.
Can a normal plugin be copied into mu-plugins?
Not safely in every case. It may rely on activation hooks, subdirectory loading or update behavior that no longer works.
Do must-use plugins make code more secure?
Not automatically. They prevent ordinary dashboard deactivation but still require secure code, updates and access controls.
Continue Learning
Previous: What Happens to Your Data When You Delete a Plugin?