Disabling the WordPress File Editor
One line removes the built-in code editor from the dashboard. It does not stop an administrator installing a plugin that edits the same files, which is why it is a hardening step rather than a lock.
This constant removes a convenience, not a capability. DISALLOW_FILE_EDIT takes the theme and plugin file editors out of the dashboard. An administrator who wants to change a file can still install a plugin that does it, or use SFTP, or use the hosting file manager. Treating the line as a lock rather than as one layer is how sites end up hardened on paper and unchanged in practice.
It is still worth setting on nearly every site, because the editor is the fastest route from a stolen administrator password to executing code, and removing it costs nothing.
The line and where it goes
define( 'DISALLOW_FILE_EDIT', true );
It belongs in wp-config.php, above this line:
/* That's all, stop editing! Happy publishing. */
Anything placed below that comment is defined after WordPress has already read the value, so the constant exists but arrives too late to have any effect. This is the single most common reason a correctly written line appears to do nothing, and it applies to every constant in the file.
What disappears
With it set, two screens stop being reachable: the theme file editor and the plugin file editor. The menu entries are removed and the URLs return a permissions error, so guessing the address does not work either.
What remains untouched:
- Installing and updating plugins and themes, including automatic updates.
- Uploading a plugin or theme zip.
- The customiser and any block editing, since neither writes PHP files.
- Any plugin that offers its own code editing, such as a snippets plugin. The constant governs the core editors, not the concept.
That last point is the one that surprises people. A site with a snippet manager installed has an in-dashboard route to running PHP regardless of this setting.
The stronger version
define( 'DISALLOW_FILE_MODS', true );
This blocks the editors and installing, updating or deleting plugins and themes. It is the right setting for a site whose code is deployed from version control, where the dashboard should never be the source of a change — the model described in WordPress and Git.
It has a consequence that has to be accepted deliberately: automatic updates stop as well. A site running this constant needs updates to arrive through deployment, and if they do not, it accumulates unpatched code. Choosing it and then not deploying is worse than not choosing it.
| Constant | Editors | Install and update | Suits |
|---|---|---|---|
DISALLOW_FILE_EDIT |
Blocked | Allowed | Most sites |
DISALLOW_FILE_MODS |
Blocked | Blocked | Deployed sites |
Where the real protection is
The constant is a UI restriction. The protections that survive a compromised administrator account live in the filesystem:
- Ownership and permissions that stop the web server user writing to theme and plugin directories. If PHP cannot write the file, no editor and no plugin can either.
- A limited number of administrator accounts. Every extra administrator is another account whose compromise reaches everything.
- Two-factor authentication on the accounts that remain, because a password alone is one leak away from useless.
Sites that skip these and set only the constant find out during cleanup that the attacker never needed the editor, which is the pattern behind most of fixing a hacked WordPress site.
When it gets in your way
Two legitimate frustrations come up. A developer used to making quick edits in the dashboard has to move to SFTP or a deployment, which is the intended outcome. And a plugin that expects the editor to exist may link to a screen that now errors, which is a cosmetic problem in the plugin rather than a sign the constant is wrong.
If you need the editor back temporarily, change the value to false rather than deleting the line, so the intent stays visible in the file. Leaving a commented-out constant with no explanation is how the next person reinstates a setting you removed on purpose.
Verify it took effect
Open Appearance and confirm there is no theme file editor entry, then open Plugins and confirm the same. Then try the editor URL directly and confirm it refuses rather than loading.
If the menu entries are still there, the line is below the stop-editing comment, or it is in the wrong file — a surprising number of edits land in a wp-config-sample.php that nothing reads. Confirming which file the site actually loads is worth one check, and debug mode is the quickest way to make the site tell you what it is running.
Frequently asked
- Not on its own. An administrator can still install a plugin, and a plugin can write files. It removes the most convenient path, not the capability, which is why it belongs alongside permissions rather than instead of them.
- DISALLOW_FILE_EDIT removes the code editor only. DISALLOW_FILE_MODS also blocks installing, updating and deleting plugins and themes, which stops automatic updates too.
- In wp-config.php, above the line that says to stop editing. Anything added below that comment runs after WordPress has bootstrapped and is ignored.