Must-Use WordPress Plugins: Benefits and Hidden Risks

A must-use plugin loads automatically from WordPress’s special mu-plugins directory.

Administrators cannot activate or deactivate it through the normal plugin controls.

That permanence solves governance problems while creating unusual operational responsibilities.

What is a must-use WordPress plugin?

It is PHP discovered inside wp-content/mu-plugins and loaded automatically.

The name means must-use, not necessarily multisite-only.

Must-use plugins work on ordinary sites

The mechanism originated around WordPress multisite history.

Current WordPress installations can use it without enabling a network.

WordPress loads them automatically

No activation record is needed for a discovered must-use file.

Removing that file effectively removes its loaded behaviour.

The official documentation defines the mechanics

The Must Use Plugins guide describes their features and caveats.

Treat those caveats as operating requirements, not trivia.

They appear in a separate administration section

WordPress lists recognised files under a dedicated Must-Use view.

They do not behave like entries within the normal active list.

Normal deactivation controls do not apply

An administrator cannot click Deactivate beside must-use code.

Filesystem or deployment access becomes the control plane.

Automatic loading prevents accidental disablement

Critical host integration or organisational policy stays active through routine administration.

This benefit matters when deactivation would damage every request.

Must-use code loads before normal plugins

Early loading can establish hooks or shared behaviour for later plugins.

It can also fail before normal plugin controls become useful.

Files load in alphabetical order

WordPress loads recognised must-use files according to their filenames.

Filename ordering is a fragile substitute for explicit hook timing.

WordPress checks only the directory root

It discovers PHP files directly inside the mu-plugins directory.

It does not automatically scan plugin files inside nested directories.

A loader can organise nested code

A top-level PHP file can require a package stored below it.

Keep loader paths explicit, validated, and covered by deployment checks.

Loader files become critical infrastructure

One broken include can prevent every bundled component from loading.

Monitor the loader and each package it includes.

Activation hooks do not run normally

Moving a normal plugin into mu-plugins bypasses its activation hook.

The official hook guide explains normal plugin activation routines.

Installation routines need another trigger

Tables, defaults, roles, or rewrite setup cannot depend on activation.

Use versioned, repeatable installation checks appropriate for automatic loading.

Deactivation hooks also lose meaning

Removing a file does not perform the normal deactivation transition.

Temporary jobs, caches, and state may therefore need explicit retirement.

Never relocate an ordinary plugin blindly

Its bootstrap may assume ordinary directories, URLs, and activation history.

Test vendor support and every lifecycle path first.

Update notifications are the biggest hidden gap

Must-use plugins do not receive normal plugin update notifications.

Your team must discover, assess, obtain, and deploy updates independently.

The dashboard cannot prove currentness

No visible update badge does not mean the code is current.

Maintain an external source, version, and advisory inventory.

Choose a trustworthy update source

Record the repository, vendor, package registry, or host owning releases.

Verify package identity before replacing executable code.

Version every deployment

Expose a reliable code version in inventory, logs, or diagnostics.

A filename alone cannot prove which revision is running.

Use source control as the authority

Store reviewed must-use code with its build and deployment definitions.

Production should not become the only surviving copy.

Do not edit production files directly

Direct edits bypass review, testing, provenance, and repeatable recovery.

Deploy an approved revision through a recorded process.

Restrict write access

Anyone changing mu-plugins can alter all requests before normal plugins load.

Grant deployment access narrowly and retain auditable change history.

Good use case: host integration

Hosts commonly use must-use code for platform-specific services and protections.

Its absence could break assumptions across the hosting environment.

Good use case: immutable organisational policy

An agency may enforce logging, environment guards, or prohibited behaviour.

The policy should have explicit owner, scope, exceptions, and review dates.

Good use case: emergency containment

Small reviewed code can temporarily block a dangerous path everywhere.

Give temporary containment an expiry and permanent remediation owner.

Good use case: early environment controls

Early code can prevent production-only actions outside the correct environment.

Fail safely when environment signals are absent or inconsistent.

Poor use case: ordinary feature plugins

Most user-facing features benefit from visible status and normal lifecycle controls.

Automatic loading adds responsibility without improving those features.

Poor use case: unreviewed copied snippets

Must-use placement does not make unknown code trustworthy.

Review source, permissions, data handling, failure behaviour, and ownership.

Poor use case: disposable experiments

Experiments need easy isolation, expiry, observation, and removal.

An always-loaded directory is the wrong default laboratory.

Keep each component narrow

One giant loader creates shared failure and unclear ownership.

Separate policies by purpose while preserving predictable bootstrapping.

Prefix or namespace global code

Early global functions and classes can collide with later components.

Use unique names and avoid unnecessary global execution.

Use hooks for timed behaviour

Early loading does not require every operation to execute immediately.

Register callbacks for the appropriate WordPress lifecycle point.

Avoid expensive work during every bootstrap

Must-use code can run across administration, frontend, cron, and API requests.

Load conditionally without skipping required security checks.

Treat a syntax error as site-wide risk

Broken early PHP can block frontend and administrator recovery paths.

Lint the exact deployed runtime version before release.

Test on the production PHP version

New syntax may parse locally and fail on an older server.

Verify extensions, configuration, and platform restrictions too.

Test every request context

Cover public pages, administration, REST, cron, CLI, login, and webhooks.

Context assumptions can break requests that humans rarely visit.

Multisite needs network-wide evidence

Must-use code loads across every site in the installation.

Test differing domains, roles, plugins, languages, and configurations.

A host may own files you cannot change

Managed platforms can install proprietary must-use components.

Confirm ownership and support before deleting unfamiliar files.

Do not hide customer-facing behaviour

Always-on code can still affect consent, privacy, tracking, or editorial output.

Document material behaviour where administrators and users can understand it.

Create a visible operational inventory

Record filename, component, owner, purpose, source, version, and deployment method.

Add dependencies, data, privileges, monitoring, and recovery instructions.

Make runtime status observable

Expose safe diagnostics showing loaded version and essential health.

Do not expose secrets, internal paths, or sensitive customer data.

Monitor the behaviour, not only the file

A present loader can still fail to include its package.

Test the policy, integration, or protection it promises.

Build a filesystem recovery route

Dashboard access may disappear when early code fails.

Keep tested SSH, hosting, SFTP, or deployment rollback access.

Recovery must identify exact targets

Document the loader, package, revision, and reversible deployment action.

A broad directory rename may disable unrelated protections.

Back up code and related state

Must-use behaviour can depend on options, tables, files, and external configuration.

The WordPress backup guide explains coordinated file and database protection.

Rehearse rollback before deployment

Restore the previous code and any coupled data safely.

Confirm platform caches and long-running workers load that revision.

Use canaries where infrastructure permits

Expose one controlled environment before every production node.

Compare errors, latency, policies, and key journeys.

Deploy atomically where possible

Partial loader and package replacements create inconsistent executable sets.

Switch a complete reviewed revision through a supported deployment mechanism.

Preserve old revisions outside the live path

Adjacent PHP backups may still be discovered and executed.

Store recovery artefacts where WordPress cannot load them.

Review compatibility before core changes

Early integrations can depend on internals changed by WordPress releases.

Test supported core versions through the complete request matrix.

Review compatibility before PHP changes

Deprecated behaviour and stricter typing can break bootstrap code immediately.

Capture warnings during staging instead of suppressing them.

Audit external calls

Early remote calls can delay every WordPress request.

Use bounded timeouts, safe fallbacks, and responsible caching.

Avoid irreversible bootstrap migrations

Automatic loading may run migration checks under concurrent requests.

Use idempotent transitions, locks, checkpoints, and tested recovery.

Plan safe retirement

Remove hooks, jobs, configuration, integrations, and obsolete data deliberately.

Confirm no normal plugin or service still expects the behaviour.

Give temporary code an expiry

Emergency fixes often outlive their incident and become undocumented infrastructure.

Assign removal criteria, owner, date, and replacement work.

Review the directory during every handoff

Explain host-owned, agency-owned, vendor-owned, and site-owned components.

Transfer repositories, deployment access, contacts, and recovery evidence.

The directory location can be customised

WordPress constants can redefine the must-use directory and public URL.

Operational documentation must reflect the actual installation configuration.

Do not confuse must-use plugins with drop-ins

Drop-ins are specially named files serving defined WordPress replacement points.

They have different discovery, purpose, status, and recovery rules.

Troubleshooting mode may leave them active

Tools disabling ordinary plugins may not disable must-use code.

Include mu-plugins explicitly when defining any conflict test.

WP-CLI inventory needs the correct status

Automation should distinguish must-use entries from active ordinary plugins.

Otherwise dashboards can undercount the executable site stack.

Core dependency declarations exclude them

WordPress does not officially support must-use plugins as declared dependencies. We wrote that up in inactive vs deleted plugins.

Deployment checks must verify required must-use components independently.

Symlinks add deployment assumptions

A symlinked loader depends on targets, permissions, release paths, and platform support.

Verify the resolved production file after every switch.

Autoloaders can collide

Early Composer loading can expose classes before ordinary plugins initialise.

Scope dependencies and test coexistence with the complete stack.

Secrets do not belong in tracked source

Load credentials through approved environment or secret-management controls.

Handle missing secrets safely without displaying their values.

Licence obligations still apply

Always-loaded placement does not remove third-party licence responsibilities.

Record source, licence, notices, distribution rights, and renewal ownership.

Support boundaries need names

Define whether the host, vendor, developer, or agency diagnoses failures.

Give responders escalation contacts and evidence requirements.

Set an explicit review cadence

Review releases, advisories, compatibility, ownership, and continued necessity.

No dashboard reminder will create that discipline for you.

Benchmark bootstrap cost

Measure time, queries, remote calls, memory, and loaded files.

Compare the same request before and after each revision.

Avoid noisy production logging

Repeated bootstrap warnings can exhaust storage and hide useful evidence.

Log actionable state with appropriate sampling and retention.

Prepare for incomplete deployments

Storage exhaustion or interrupted transfers can leave mixed package files.

Verify hashes, counts, permissions, and loaded version after deployment.

Preserve an emergency bypass carefully

Some critical policies need a tested, restricted recovery bypass.

Protect access and audit every use.

Check disaster restoration order

Must-use code may expect secrets, services, tables, or normal plugins.

Restore prerequisites before allowing public requests.

Document expected absence during maintenance

A deployment may intentionally remove one component briefly.

Prevent traffic or provide safe behaviour during that state.

Audit privileged operations

Early code may change authentication, roles, requests, or platform configuration.

Require capability checks, input validation, and escaped output.

Keep human-readable operating notes

Explain why the component must load, not only what it executes.

Future maintainers need decisions, risks, contacts, and removal criteria.

Know the honest weak case

An ordinary plugin is often operationally safer than a must-use plugin.

Prefer normal controls when accidental deactivation is not catastrophic.

Use the must-use plugin checklist

1. Prove automatic loading is necessary.
2. Name the behaviour and owner.
3. Confirm host ownership before changes.
4. Inventory loader and package files.
5. Record source and deployed version.
6. Replace activation-dependent setup.
7. Test alphabetical loading assumptions.
8. Test every request context.
9. Test production PHP compatibility.
10. Review security and privacy behaviour.
11. Define independent update discovery.
12. Deploy complete reviewed revisions.
13. Monitor promised runtime behaviour.
14. Rehearse filesystem recovery.
15. Document retirement and handoff.

Frequently asked questions

The verdict

Always-on code deserves stronger governance, not weaker scrutiny. Review WP Block Suite’s $299 lifetime licence.