Disable File Editing With DISALLOW_FILE_EDIT

What this check and mySites.guru tool looks at on your site

This check reads your site’s wp-config.php for the DISALLOW_FILE_EDIT constant and confirms it’s both defined and set to true. If the constant is missing entirely, or present but set to false, the check fails.

The fastest route from stolen credentials to running code

WordPress ships with a built-in code editor, tucked under Appearance → Theme File Editor and Plugins → Plugin Editor, that lets anyone with an administrator account open any theme or plugin PHP file, edit it in a browser textarea, and save it straight back to disk. The change takes effect on the very next page load, with no deployment step, no file permissions to fight with, and no trace beyond whatever your host’s own file-change logging happens to catch.

That convenience is exactly the problem. If an attacker gets hold of valid administrator credentials, through a leaked password, a phished login, or a vulnerable plugin that lets them escalate privileges, the theme editor is usually the fastest route to running their own PHP on your server. There’s no upload step to trip a file-type restriction and no plugin install to leave an obvious new entry in your plugins list. They open functions.php, paste in whatever they want, and it’s live immediately. DISALLOW_FILE_EDIT removes that specific screen from the admin area entirely, for every user, administrators included, so that route simply isn’t there to use.

It’s worth being precise about what this constant does and doesn’t do. It’s one layer in a defence-in-depth approach, not a complete fix for a compromised admin account. An attacker with real admin access can still install a plugin from the repository, or one they’ve uploaded, and get the same outcome a different way. DISALLOW_FILE_EDIT closes the single fastest, quietest path, not every path.

It’s also worth noticing why this particular route gets used so often in practice. Installing a new plugin leaves an obvious trace: a new entry in the plugins list, a new set of files with a recent modification date, something a site owner glancing at their dashboard might notice. Editing an existing, already-trusted file through the theme editor leaves almost nothing comparable. The file was already there, already active, and already excluded from most people’s mental model of “things that might have changed.” That’s precisely the quality that makes it worth removing as an option entirely, rather than relying on anyone noticing after the fact.

Set to true, permanently

DISALLOW_FILE_EDIT should be defined and set to true in wp-config.php on every live site:

define( 'DISALLOW_FILE_EDIT', true );

There’s rarely a good reason to leave this off permanently on a production site. If you genuinely need the in-admin editor for a specific piece of work, the better pattern is to enable it temporarily, make the change, and set it back to true immediately afterwards, rather than leaving the door open by default.

If you find yourself reaching for the theme editor regularly enough that toggling this constant back and forth feels like friction, that’s usually a sign the underlying workflow needs fixing rather than a reason to leave the constant off. A version-controlled deployment process, or even routine SFTP access for the person making changes, achieves the same outcome without leaving a standing route into the codebase for anyone who gets into the admin account, intentionally or not.

How to fix it

1. Connect to your site via SFTP, SSH, or your hosting control panel’s file manager, and open wp-config.php in the site root.
2. Find the line that reads /* That's all, stop editing! Happy publishing. */ and add the constant on its own line, before it:

define( 'DISALLOW_FILE_EDIT', true );

3. Save the file and confirm the change took effect: log into https://yoursite.com/wp-admin, and check that Appearance → Theme File Editor and Plugins → Plugin Editor are no longer listed in the menu.
4. If you manage a multisite network, be aware that setting this in the network’s shared wp-config.php applies it across every site in the network at once, which is usually what you want, rather than needing to repeat the change per site.
5. If you need to make a manual code change later, edit the file directly over SFTP or SSH instead of re-enabling the constant. If you must re-enable it temporarily, set it back to true as soon as the change is made.

What mySites.guru does about it

mySites.guru checks every connected WordPress site for this constant on each snapshot, twice a day, and can set DISALLOW_FILE_EDIT to true in wp-config.php with one click, across every connected site at once, rather than editing each one by hand.