Set DISALLOW_FILE_MODS on a client site when the agency manages code through a deploy pipeline and the client does not need to install anything from the dashboard. It blocks plugin, theme and core changes from wp-admin, which removes a route attackers use, but it also stops dashboard updates.
The WordPress wp-config documentation describes the constant and says that setting it also disables the plugin and theme file editor, so you do not need to set DISALLOW_FILE_EDIT as well.
What it does in plain words
With define( 'DISALLOW_FILE_MODS', true ); in wp-config.php, the dashboard can no longer install, update or delete plugins and themes, and it cannot edit their files. Code changes have to arrive some other way, such as a deploy from a repository.
The hardening guide explains why the editor matters: the dashboard lets administrators edit PHP files by default, which it calls often the first tool an attacker will use after logging in, because it allows code execution.
The two constants compared
| Setting | Blocks editing in dashboard | Blocks install and update in dashboard |
|---|---|---|
| DISALLOW_FILE_EDIT | Yes | No |
| DISALLOW_FILE_MODS | Yes | Yes |
The trade off
The upside is a smaller set of actions a stolen administrator login can take. The cost is that nobody can click Update. If your process relies on the dashboard, a locked site quietly stops receiving updates, and that is a security regression.
So the rule is: only use it when you have a replacement. That means a repository, a pipeline, and a routine for applying updates through Composer or another controlled path. Composer's documentation recommends committing the lock file so the whole team runs the same versions, which fits this model.
A checklist before enabling
- Confirm the code lives in version control.
- Confirm updates can be applied by deploy, and test one on staging.
- Confirm backups run and a restore has been tested.
- Tell the client what will change: they will not see update buttons.
- Add the setting to the handover document with the reason.
- Set a calendar item to check that updates are actually being applied.
What it does not do
It does not stop vulnerable code from running, does not remove a malicious plugin already installed and does not stop an attacker who can write files through another route, such as a compromised hosting account. File permissions matter as well. The handbook suggests plugin directories be writable only by your user account.
Which clients should not use it
Small clients who manage their own site and rely on the dashboard for updates are usually better served by keeping updates on, with auto-updates for low risk plugins and a tested backup. Pick the model that will actually be followed.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request is checked before it merges; that review step is what replaces the dashboard when file changes are locked.
Safeguard's policies and gates apply to code changes in repositories, and the free scan shows the dependency checks.
Quick check
Does DISALLOW_FILE_MODS replace DISALLOW_FILE_EDIT?
Per the wp-config documentation, on its own it has the same effect on the file editor, plus it blocks installs and updates from the dashboard.
Will the site still get security updates?
Only if you apply them another way, such as a deploy pipeline. Without one, locking the dashboard stops updates.
Sources
Last reviewed: 19 October 2026.
