Lock WordPress Admin: DISALLOW_FILE_EDIT vs DISALLOW_FILE_MODS

If you want to stop anyone from editing theme and plugin code inside the WordPress dashboard, add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. If you also want to stop plugin and theme installs and updates from the dashboard, use define( 'DISALLOW_FILE_MODS', true ); instead. Most sites should start with the first one.

Here is the catch. One line in wp-config.php removes the dashboard code editor, but the stronger constant also blocks plugin updates, so you need to pick the right one on purpose.

By the end of this guide you will be able to add either line safely, check that it worked, and fix the common problems people hit afterwards.

What is the dashboard file editor, and why lock it?

The official WordPress hardening guide says it plainly: "The WordPress Dashboard by default allows administrators to edit PHP files, such as plugin and theme files." PHP files are the code that runs your site, so a change there takes effect right away.

Think of it like leaving a screwdriver taped to the back of your front door. It is handy for you. It is just as handy for anyone who gets through that door.

If someone steals an admin password, the editor lets them paste code into your theme without needing FTP or SFTP (ways to move files to the server) at all. The same guide adds a fair warning about the fix: "This will not prevent an attacker from uploading malicious files to your site, but might stop some attacks."

There is a second risk that has nothing to do with attackers. The WordPress documentation for the theme editor warns: "The editor does not make backup copies. If you introduce an error that crashes your site, you cannot use the editor to fix the problem."

Why this matters: most people never use the editor on a live site. Turning it off costs you almost nothing and closes one easy door.

Before you start

Check these before you touch anything:

• You can log in to wp-admin as an administrator, so you can confirm the change afterwards.
• You can reach your site files through your host's File Manager or an SFTP client.
• You have a full backup of the site, plus a separate copy of wp-config.php saved on your own computer.
• You have a staging copy (a private test copy of your site), or a quiet time when a few minutes of downtime will not hurt.
• You know your risk level: DISALLOW_FILE_EDIT is low risk, while DISALLOW_FILE_MODS changes how you update the site and needs a plan.

If you do not have a recent backup, sort that out first. Our guide on how to migrate WordPress without FTP using cPanel and Backup walks through taking a full copy of your files and database.

Adding the line to wp-config.php

The file wp-config.php is WordPress's main settings file. The wp-config documentation says it is "located in the root of your WordPress file directory", which is the same folder that holds wp-admin and wp-content.

Step 1: Back up wp-config.php

Open your host's File Manager or your SFTP client and go to the folder where WordPress is installed. Download wp-config.php to your computer before you change a single character.

You should now have a copy of wp-config.php on your computer that you can open in a text editor.

Quick tip: keep the backup on your own computer, not as an extra copy inside your website folder. This file holds your database password, and you want as few copies of it on the web server as possible.

Step 2: Find the right spot in the file

Open wp-config.php in your File Manager's editor or a plain text editor. Scroll down until you find the comment that marks the end of the settings area.

At the time of writing (13 November 2026), the sample config file that ships with WordPress contains this comment:

/* That's all, stop editing! Happy publishing. */

Your file may be older or edited by your host, so the wording can differ. What matters is where you put your line: above that comment, and above the line that loads wp-settings.php.

Heads up: a line placed after require_once ABSPATH . 'wp-settings.php'; comes too late. WordPress has already loaded by then, so your setting may not take effect.

Step 3: Add DISALLOW_FILE_EDIT

This line turns off the theme and plugin code editors in the dashboard for every user:

define( 'DISALLOW_FILE_EDIT', true );

Paste it on its own line, above the "stop editing" comment. Make sure it ends with the semicolon and that true has no quotes around it.

According to the hardening guide, this line "is equivalent to removing the" edit_themes, edit_plugins and edit_files "capabilities of all users". A capability is a named permission WordPress checks before it shows a screen or allows an action.

The WordPress core code confirms how it works. In map_meta_cap() (the function that turns permission checks into real rules), if DISALLOW_FILE_EDIT is set, the edit_files, edit_plugins and edit_themes checks are mapped to do_not_allow, which means nobody passes them.

Step 4: Or add DISALLOW_FILE_MODS instead

This line blocks plugin and theme installs and updates from the dashboard, and it also turns off the code editors:

define( 'DISALLOW_FILE_MODS', true );

The wp-config documentation describes it this way: "This will block users being able to use the plugin and theme installation/update functionality". It also says: "Setting this constant also disables the Plugin and Theme File editor".

So you do not need both lines. If you add DISALLOW_FILE_MODS, the editor is already covered.

The function WordPress uses to decide is wp_is_file_mod_allowed(). Its source is one line:

return apply_filters( 'file_mod_allowed', ! defined( 'DISALLOW_FILE_MODS' ) || ! DISALLOW_FILE_MODS, $context );

In plain words: file changes are allowed unless DISALLOW_FILE_MODS is defined and true. A filter called file_mod_allowed can then change that answer, and it is given a context string that says what kind of change is being checked.

Step 5: Save and reload the site

Save wp-config.php, then load your home page and wp-admin in a browser. Both should load normally.

If the site goes blank or shows an error, do not panic. Put back your backup copy of wp-config.php and look at the troubleshooting section below.

DISALLOW_FILE_EDIT or DISALLOW_FILE_MODS: which to pick

Here is how the two compare:

• DISALLOW_FILE_EDIT removes the theme and plugin code editors without blocking normal installs or updates. WordPress also warns that a plugin which incorrectly uses current_user_can( 'edit_plugins' ) as a general permission check can be affected, so test plugin workflows after enabling it.
• DISALLOW_FILE_MODS removes the editors too, and it also blocks installing, updating and deleting plugins and themes, plus core updates, from the dashboard.
• With DISALLOW_FILE_EDIT, plugin and theme updates keep working as before, including any automatic updates you have switched on.
• With DISALLOW_FILE_MODS, the automatic updater is switched off as well. The core method WP_Automatic_Updater::is_disabled() returns true when wp_is_file_mod_allowed( 'automatic_updater' ) is false.
• DISALLOW_FILE_MODS also feeds into language pack functions such as wp_can_install_language_pack() and wp_download_language_pack(), which both appear in the "Used by" list for wp_is_file_mod_allowed().
• DISALLOW_FILE_EDIT suits almost every site, including ones managed only through wp-admin.
• DISALLOW_FILE_MODS suits sites where code is deployed some other way, such as by a developer through git or SFTP, or where the host handles updates.

The 2013 Make WordPress Core post on disabling auto updates, written by Andrew Nacin for WordPress 3.7, put it bluntly: "The DISALLOW_FILE_MODS constant blocks any kind of filesystem changes", and it applies to every user. The same post lists what goes away: "the file editors; the ability to update core, themes, or plugins; and the ability to install" new ones.

That post is from 2013. Treat it as documented behaviour from that time, not as a current test result, and test the behaviour on your own staging copy before you rely on it.

Why this matters: a site with DISALLOW_FILE_MODS and no update plan slowly falls behind on security fixes. That is often worse than leaving the editor on.

A made-up example

This is an invented scenario to show the trade-off. Sara runs a small shop site. She adds DISALLOW_FILE_MODS because a forum post said it was "the secure one", then forgets about it.

Three months later a popular form plugin ships a security fix. Sara's dashboard never installs it, and no automatic update runs either. Her site sits on the old version until her developer notices. With DISALLOW_FILE_EDIT, the editor would have been gone and the update would have landed as normal.

Other ways to apply and protect the setting

Using WP-CLI

WP-CLI is the official command line tool for WordPress. Its wp config set command "Sets the value of a specific constant or variable defined in wp-config.php file."

This command adds DISALLOW_FILE_EDIT with a real true value (run it from your WordPress folder over SSH):

wp config set DISALLOW_FILE_EDIT true --raw

The --raw flag matters. The WP-CLI docs say it will "Place the value into the wp-config.php file as is, instead of as a quoted string." Without it, you would get the text 'true' in quotes instead of the PHP value true.

By default the command adds the constant if it is missing. The docs describe an anchor option, the string new values are placed around, and its default is the "stop editing" comment, which is the same safe spot we picked by hand. You should see a line starting with Success: when it finishes.

This command does the same for the stronger constant:

wp config set DISALLOW_FILE_MODS true --raw

Protecting wp-config.php on Apache

Locking the editor is one layer. It also makes sense to protect the config file itself, because it holds your database password.

The hardening guide gives this block for servers that use .htaccess, and says to put it "at the very top" of that file. This block tells Apache to refuse any web request for wp-config.php:

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

After adding it, open https://example.com/wp-config.php in your browser (with your own domain). You should get an access denied or forbidden error instead of a blank page.

The same guide offers two more options. "You can move the wp-config.php file to the directory above your WordPress install." It also says to make sure "only you (and the web server) can read this file (it generally means a 400 or 440 permission)."

This command sets the file to 440 from the WordPress folder, if your host allows it and the web server user can still read the file:

chmod 440 wp-config.php

Heads up: with 440, you can no longer save the file in place. Change it back to a writable permission when you need to edit, then lock it again.

What about Nginx?

DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS are PHP constants inside wp-config.php. They work the same on Nginx, Apache, LiteSpeed or anything else that runs PHP, so the steps above do not change.

The Apache block is different. The WordPress Nginx guide says: "With Nginx there is no directory-level configuration file like Apache's .htaccess or IIS's web.config files." Your .htaccess rules are simply ignored there.

On Nginx, the rule lives in the server block. Nginx's location = form matches one exact URI, and deny all; refuses the request. This block, placed inside your site's server block, blocks direct requests for the file:

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

After you reload Nginx, a request for https://example.com/wp-config.php should return a forbidden error. If you are on shared hosting without access to Nginx config, ask your host to add it.

How to check it worked

Check the file editors are gone

Log in to wp-admin as an administrator. At the time of writing (13 November 2026), current WordPress core code places the Theme File Editor under Appearance for classic themes and under Tools for block themes. The Plugin File Editor sits under Plugins for classic themes and under Tools for block themes.

With either constant set, those menu items should be gone. If you type the editor address in directly, such as https://example.com/wp-admin/theme-editor.php, you should see this message:

Sorry, you are not allowed to edit templates for this site.

Check plugin installs are blocked (DISALLOW_FILE_MODS only)

If you used DISALLOW_FILE_MODS, look under Plugins. At the time of writing, the current core menu labels the install screen Add Plugin, and it should no longer appear.

Visiting https://example.com/wp-admin/plugin-install.php directly should show this message:

Sorry, you are not allowed to install plugins on this site.

If you only used DISALLOW_FILE_EDIT, the install screen should still be there. That is correct.

Check from the command line

This command shows the value WP-CLI reads from wp-config.php for the constant:

wp config get DISALLOW_FILE_EDIT

You should see true.

This command asks WordPress itself whether file changes are allowed, using the wp eval command (which runs a piece of PHP with WordPress loaded):

wp eval 'var_dump( wp_is_file_mod_allowed( "manual_check" ) );'

With DISALLOW_FILE_MODS set to true, you should see bool(false). Without it, you should see bool(true), unless a plugin is using the file_mod_allowed filter to change the answer.

Troubleshooting

Blank page or server error right after saving

Symptom: the site or wp-admin will not load at all after you edit wp-config.php.

Cause: usually a small typing mistake, such as a missing semicolon, a missing quote, or a curly quote pasted from a word processor. The PHP manual says PHP "requires instructions to be terminated with a semicolon at the end of each statement."

Fix: upload your backup copy of wp-config.php, then add the line again carefully in a plain text editor. Compare it character by character with the code block in Step 3.

Odd output or header warnings after a closing tag

Symptom: strange spaces or characters at the top of pages, or warnings about headers, after you edited the end of the file.

Cause: text or blank lines after a closing ?> tag at the very end of the file. The PHP manual says the closing tag at the end of a file "is optional", and leaving it out helps "so unwanted whitespace will not occur at the end of files". At the time of writing, the current wp-config-sample.php ends with the require_once line and no closing tag.

Fix: make sure nothing comes after the final ?> if your file has one, not even a blank line. Never add your define line below the end of the file.

The editor menu is still there

Symptom: you added the line, but Theme File Editor still shows.

Cause: the line is below the wp-settings.php line, the constant name has a typo, or you edited a different copy of wp-config.php (for example a staging copy, or the original after you moved it one folder up).

Fix: move the line above the "stop editing" comment, copy the constant name exactly from this guide, and run wp config get DISALLOW_FILE_EDIT to confirm which value is saved in the file you are editing.

You set it to false, but the editor is still disabled

Symptom: you wrote 'false' to turn it back on, and nothing changed.

Cause: in PHP, a quoted 'false' is a non-empty string, and the PHP manual says only a few values count as false, such as the empty string and the string "0". "Every other value is considered true".

Fix: to turn it off, delete the line, or write false with no quotes. The same applies to true: use it without quotes, which is why the WP-CLI command uses --raw.

Plugin updates quietly stopped

Symptom: weeks pass and no plugin updates are installed, and you see no update buttons in wp-admin.

Cause: DISALLOW_FILE_MODS is set. It blocks dashboard updates and also turns off the automatic updater, as the is_disabled() source shows.

Fix: run wp config get DISALLOW_FILE_MODS to confirm. Then either switch to DISALLOW_FILE_EDIT, or set up a clear way to update the site outside the dashboard, such as a developer deploying new plugin versions through SFTP or git.

A developer needs to edit a theme file

Symptom: your developer asks you to "just turn the editor back on for a minute".

Cause: with the constant set, the editors are blocked for everyone, including administrators.

Fix: the better path is for them to edit the file through SFTP on a staging copy, then deploy it. If you must, remove the line, let them make the change, and put the line back the same day. Keep a note so it does not stay off by accident.

Pro tips and when to ask for help

Quick tip: if you use a security plugin, look through its settings for anything about the file editor. Knowing which tool is in charge of that setting saves time when you troubleshoot later.

Quick tip: the editor lock helps most when stolen passwords cannot be used easily in the first place. Pair it with two-factor login, as covered in our guide to two-factor authentication on cPanel, Plesk and DirectAdmin.

If you run your own server, the file editor is only one door. Our Fail2Ban SSH protection guide for VPS servers covers blocking repeated login attempts at the server level.

Ask your host or developer before using DISALLOW_FILE_MODS if you are not sure who applies updates on your site. Ask them too if you are on a multisite network, because in core code the theme editor on multisite redirects to the network admin, so the behaviour you see may differ.

The one message worth forwarding

If someone else manages your site, you can send them this:

Hi, I'd like to lock down code editing in our WordPress dashboard.

Please add this line to wp-config.php, above the "stop editing" comment and above the wp-settings.php line:

define( 'DISALLOW_FILE_EDIT', true );

Please do not use DISALLOW_FILE_MODS unless you also have a plan for applying plugin, theme and core updates outside the dashboard, because it blocks those updates and the automatic updater.

Also please block web access to wp-config.php (Apache: a Files block with "Require all denied"; Nginx: a location rule with "deny all"), and confirm the file permissions are as tight as our setup allows.

Once done, can you confirm that Theme File Editor no longer appears in wp-admin and that plugin updates still work? Thanks.

The takeaway: use DISALLOW_FILE_EDIT on almost every site, and reach for DISALLOW_FILE_MODS only when someone has a real plan for updates.