How to Disable the Theme and Plugin Editor with DISALLOW_FILE_EDIT

Hidden in every default WordPress install are two pages that almost no one uses on purpose, but that quietly turn a stolen admin password into a full server compromise. Appearance, Theme File Editor and Plugins, Plugin File Editor. Both let an admin edit raw PHP files inside the installation directly through the browser. Both are still on by default in 2026. And both are entirely optional.

This guide explains why turning the editors off is one of the highest leverage hardening changes you can make on a WordPress site, what the single line of config looks like, and what to expect afterwards (including a couple of edge cases that surprise people).

Why is the built in code editor a problem?

On a normal day, no one uses the editor. Theme changes go through a child theme or a developer's deploy pipeline. Plugin changes happen on staging, not in production. The editor sits there, unused, accessible only to administrators.

"Accessible only to administrators" is the part that breaks under attack. The way the typical WordPress takeover plays out has nothing to do with code level vulnerabilities in the editor itself. It looks like this:

1. An admin password is leaked. Phishing, password reuse from a breached service, a developer laptop with malware, a compromised plugin that exfiltrates session cookies. Pick any of the usual entry points.
2. The attacker logs in to /wp-admin as a real admin user. From WordPress's perspective, nothing is wrong, this is a legitimate login.
3. The attacker walks straight to Appearance, Theme File Editor, opens functions.php, and pastes a small PHP backdoor at the top.
4. From that moment on, every request to the front page of the site executes the attacker's code. They have a remote shell on your server.

The editor turns "stolen admin password" into "stolen webserver". Without it, an attacker who steals an admin password still has admin access (which is bad enough), but they have to take the slower, noisier route of uploading a malicious plugin or theme zip to get code execution. That extra step is one more chance for a security plugin, a file integrity scanner or a server level WAF to notice and block the upload.

The cost benefit is wildly skewed. The editor is used a few times a year by a tiny minority of admins. The risk shows up on every site that gets a credential leak. Disabling the editor is one of those changes where the worst case is "someone has to use SFTP for a five minute edit" and the best case is "the takeover never escalates from password leak to backdoor".

The fix: a single line in wp-config.php

WordPress has a built in constant for exactly this case. Open wp-config.php in the WordPress root directory and add the following line, anywhere above the comment that says /* That's all, stop editing! Happy publishing. */:

define('DISALLOW_FILE_EDIT', true);

Save the file. That is it. The Theme File Editor menu under Appearance and the Plugin File Editor under Plugins disappear immediately for every user, including administrators. The pages themselves return a permission error if accessed directly via URL. There is no plugin to install, no setting to maintain, no compatibility surface to worry about. The constant has been part of WordPress core since version 3.0 (released in 2010) and is not going anywhere.

What if I also want to block plugin and theme uploads from the admin?

WordPress has a stricter sibling constant called DISALLOW_FILE_MODS. It does what DISALLOW_FILE_EDIT does, plus blocks plugin uploads, theme uploads and core updates from inside the admin interface. Setting it looks identical:

define('DISALLOW_FILE_MODS', true);

That one is a much bigger change in behavior. With DISALLOW_FILE_MODS active, you can no longer install or update plugins, themes or WordPress core through the normal admin interface. All updates have to come from somewhere else: WP CLI, a deploy pipeline, an SFTP upload, or a managed host's central dashboard.

For most sites that is too restrictive. Updates are the single most important security task on a WordPress site, and making them harder usually means people skip them. DISALLOW_FILE_MODS makes sense in two specific environments: deploy pipelines where the production install is meant to be read only, and high security setups where someone is genuinely responsible for pushing updates from outside. For everything else, plain DISALLOW_FILE_EDIT hits the sweet spot of "huge security gain, no operational pain".

What changes for users after you set it?

For 99% of admins on 99% of sites: nothing visible. The two menu entries are gone from the dashboard. No one notices, because no one was using them.

The cases where someone does notice:

• A developer who edits production directly. If you have someone in the team who routinely edits theme or plugin files through the browser, they will need to switch to SFTP or a deploy pipeline. That is a workflow change, not a blocker. If anything, this is a good moment to ask why production code is being edited live in the first place.
• Plugins that hook into the editor. A small handful of plugins extend the built in editor with extra features. They will silently fail to load their UI when the editor is gone. The plugin itself usually keeps working, only the editor integration breaks. If you depend on one of those, you will see the gap during testing.
• Custom code that uses edit_themes or edit_plugins capabilities. The constant strips those capabilities from every role, including administrator. Code that gates features on those exact capabilities will behave as if no one has them. Rare, but worth knowing if you maintain a custom plugin that does this kind of capability check.

Verifying that it is active

1. Log in to WordPress as an administrator.
2. Open the Appearance menu in the admin sidebar. The "Theme File Editor" entry should be missing.
3. Open the Plugins menu. The "Plugin File Editor" entry should be missing.
4. For an extra check, navigate directly to https://yourdomain.com/wp-admin/theme-editor.php. WordPress should redirect you to a page that says "Sorry, you are not allowed to edit theme files".
5. Run a fresh InspectWP scan. The "file editor enabled" check in the security section should turn green.

If the menu entries are still there after you saved wp-config.php, the most common reasons are: object cache (clear it), opcode cache like OPcache (it may take a moment to pick up the new file, or you can restart PHP FPM), the file edit landed in a wrong wp-config.php in a parent directory, or the constant was set later in the file by something else and your line is being overridden. Open wp-config.php from the very top and search for DISALLOW_FILE_EDIT; you should see your line and nothing else setting it again afterwards.

What this fix does and does not do

It is worth being clear about what kind of attack DISALLOW_FILE_EDIT stops, and what it leaves untouched. It stops the specific path where an attacker uses a stolen admin login to write PHP into theme or plugin files via the browser. It does not stop:

• An attacker uploading a malicious plugin or theme zip from the admin (use DISALLOW_FILE_MODS for that, with the trade offs described above, or restrict capabilities for plugin uploads).
• An attacker exploiting a code level vulnerability in a plugin to write files. That requires the plugin itself to be patched.
• An attacker who has SFTP or shell access. At that point the WordPress layer is bypassed entirely.

DISALLOW_FILE_EDIT is one defensive layer, not a complete strategy. It pairs naturally with strong admin passwords, two factor authentication on admin accounts, and a security plugin that watches for unexpected file changes. The combination removes the easiest takeover path and makes the harder ones loud enough to notice.

One line in wp-config.php, no plugin, no maintenance, no compatibility surface. If you do nothing else on a WordPress site this month, do this.