Disabling WordPress Theme & Plugin File Editors: DISALLOW_FILE_EDIT

This article is a localized edition of the Japanese original. Read the Japanese original

The WordPress admin includes "file editors" that let you rewrite theme and plugin files (PHP, CSS and so on) directly in the browser. They are convenient, but if an administrator account is hijacked, an attacker can write arbitrary PHP code through these screens and run it on your server. A mistake while editing can also take your site down.

Adding one line that defines the constant DISALLOW_FILE_EDIT in wp-config.php disables these file editors for everyone, administrators included. This article explains how to set it, what it does and does not block, and how it differs from the stronger DISALLOW_FILE_MODS. It is based on the WordPress source code as of October 2026.

Which file editors are affected

Add DISALLOW_FILE_EDIT to wp-config.php

Before you start, make a copy of wp-config.php.

cd /var/www/html
sudo cp -p wp-config.php wp-config.php.bak
sudo nano wp-config.php

Add the following line above the line That's all, stop editing! in wp-config.php (a translated comment in localized versions of the file). If you put it below that line, it comes after WordPress has started loading and may not take effect.

define( 'DISALLOW_FILE_EDIT', true );

If WP-CLI is available, you can also add it with the following commands. --raw writes true as a boolean rather than a string.

wp config set DISALLOW_FILE_EDIT true --raw
wp config get DISALLOW_FILE_EDIT

wp-config.php is a PHP file, so edit it over SSH or SFTP, or with your hosting provider's file manager. If the site stops loading after you save, check for a missing semicolon or mismatched quotes at the end of the line, and restore the backup if you cannot fix it.

Check the result

• Theme File Editor and Plugin File Editor no longer appear in the admin menu
• Opening https://example.com/wp-admin/theme-editor.php directly shows a message that you are not allowed to access it

With WP-CLI, you can confirm that the administrator no longer has editing capabilities (replace admin with your administrator user name).

wp eval 'var_dump( current_user_can( "edit_plugins" ), current_user_can( "edit_themes" ) );' --user=admin
# If you see bool(false) twice, the editors are disabled

What it blocks and what it doesn’t

When DISALLOW_FILE_EDIT is true, WordPress denies the capabilities edit_files, edit_plugins and edit_themes to every user, administrators included. Because it works at the capability check, it does more than hide the menus: the screens cannot be used even if you open their URLs directly.

On the other hand, the following features are not affected by this setting:

In other words, DISALLOW_FILE_EDIT closes only the path of "rewriting PHP files from the admin screen." Administrators can still upload and install plugins, so combine it with protecting the administrator accounts themselves (strong passwords, two-factor authentication, and as few administrators as possible).

A stronger restriction: DISALLOW_FILE_MODS

Setting DISALLOW_FILE_MODS to true blocks the file editors and also installing, updating and deleting plugins and themes from the admin, plus WordPress core updates (including automatic updates).

define( 'DISALLOW_FILE_MODS', true );

With this setting, security updates are not applied from the admin either. Use it only when you have a process that keeps updates going by other means, such as deploying files through Git or a deployment pipeline. Otherwise, using DISALLOW_FILE_EDIT alone avoids the risk of falling behind on updates.

Do not edit core files

Do not add your own checks to WordPress core files such as wp-admin/admin.php. Core updates overwrite and remove them, and a mistake can lock you out of the entire admin. Restricting the file editors with a constant in wp-config.php is the method WordPress provides.

Also protect wp-config.php

Separately from disabling the file editors, it is worth protecting wp-config.php itself. wp-config.php normally runs as PHP, so its contents are not displayed, but deny direct web access in case PHP stops working or something similar happens.

For Apache 2.4 (in the .htaccess of the WordPress directory):

<Files wp-config.php>
    Require all denied
</Files>

For Nginx (inside the server block):

location = /wp-config.php {
    deny all;
}

Order Allow,Deny and Deny from all are Apache 2.2 syntax. On Apache 2.4, use Require all denied.

Keep the file permissions as narrow as possible while still letting the web server user read the file (for example, 440 or 400). Depending on the owner and group setup, the file may become unreadable, so confirm that the site still loads after the change.

When you need to edit themes or plugins

After disabling the file editors, edit files in one of these ways:

• Create a child theme, edit it in a local editor and upload it over SFTP (if you edit the parent theme directly, theme updates erase your changes)
• Edit and test on a staging environment, then deploy to production
• Put small feature additions in your own plugin or in mu-plugins rather than in the theme

Summary

• Add define( 'DISALLOW_FILE_EDIT', true ); above the "That's all, stop editing!" line in wp-config.php
• The capabilities edit_files, edit_plugins and edit_themes are denied to everyone, and the Theme and Plugin File Editors can no longer be used
• Installing and updating plugins, the Site Editor and Additional CSS keep working
• Use DISALLOW_FILE_MODS, which also stops installs and updates, only when you can run updates by other means
• Do not edit core files (such as wp-admin/admin.php)

Related articles:

• How to protect wp-config.php
• Setting WordPress file permissions
• Basic WordPress security measures

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)