Lock Down WordPress: Turn Off the File Editor in wp-config.php

To turn off the built-in plugin and theme file editor in WordPress, add define( 'DISALLOW_FILE_EDIT', true ); to your wp-config.php file, above the line that says "That's all, stop editing!". If you also want to block installing and updating plugins and themes from the dashboard, add define( 'DISALLOW_FILE_MODS', true );, but only after you have a different way to apply updates.

Here is a detail most people miss: the WordPress documentation for the Theme File Editor says plainly that "the editor does not make backup copies." One wrong character saved in a live theme file can take the whole site down, and the same editor cannot help you fix it.

By the end of this guide you will be able to lock the editor, decide whether to lock file changes too, protect wp-config.php itself, and prove that every change worked.

What locking wp-config.php actually is

wp-config.php is the main settings file of a WordPress site. It holds your database login and a list of constants, which are fixed named settings that WordPress reads every time a page loads.

Two of those constants control how much power the admin dashboard has over your files. DISALLOW_FILE_EDIT removes the code editors for plugins and themes. DISALLOW_FILE_MODS goes further and also stops the dashboard from installing or updating plugins and themes.

Think of your site as a shop. The admin dashboard is the front counter, and the code editor is a door from the counter straight into the back office where the wiring lives. Locking the editor does not close the shop. It just means that anyone who gets behind the counter, including a thief with a stolen password, cannot walk straight into the wiring room.

Why this matters: the WordPress hardening handbook says that setting DISALLOW_FILE_EDIT is equivalent to removing the edit_themes, edit_plugins and edit_files capabilities from all users. A capability is a single permission, like "can edit plugins", that WordPress gives to a user role.

Heads up: the same handbook is honest about the limit. It says this "will not prevent an attacker from uploading malicious files to your site, but might stop some attacks." So treat it as one layer, together with good file permissions and strong admin logins.

Before you start

Run through this list first. It takes a few minutes and saves you from the worst surprise, which is a site that will not load.

• Access: SFTP, SSH, or your hosting control panel file manager. In cPanel that is File Manager.
• Logins: your hosting account and one WordPress administrator account, so you can test the result.
• Tools: a plain text editor, or WP-CLI if your host has it. WP-CLI is the command line tool for managing WordPress.
• Backup: a copy of the current wp-config.php, stored outside your public web folder. Step 1 shows how.
• Time: about 20 minutes for the editor lock, plus 10 minutes if you also lock file changes and tighten permissions.
• Risk level: low for DISALLOW_FILE_EDIT. Medium for DISALLOW_FILE_MODS, because it changes how you update plugins and themes.

Lock the file editor in wp-config.php

This is the main change. Do it first, test it, then decide whether you want the stronger lock.

Step 1: Back up wp-config.php

If you have SSH, this command copies the file to your home folder, outside the public web root, with today's date in the name. Run it from the folder that holds wp-config.php.

cp wp-config.php ~/wp-config-backup-2026-11-07.php

In cPanel, open File Manager, select wp-config.php, click Copy in the toolbar, and enter a destination path outside public_html, for example your home folder. You can also right-click the file and choose Download to keep a copy on your computer.

Heads up: do not leave copies such as wp-config.php.bak or wp-config.old inside the public folder. The server may not treat those names as PHP, which means it could send the file, passwords included, as plain text to anyone who guesses the name.

You should now see the backup in your home folder or your downloads, and the original file untouched.

Step 2: Open wp-config.php for editing

Over SSH, open the file in your usual editor. In cPanel File Manager, select wp-config.php and click Edit.

If you cannot see the file, it may be hidden by display settings or sitting somewhere unusual. In File Manager, open Settings, tick Show Hidden Files (dotfiles), and click Save. The hardening handbook also notes that wp-config.php "can be stored ONE directory level above" the WordPress install, so look in the folder above public_html too.

Step 3: Add DISALLOW_FILE_EDIT

Find the comment line that starts with /* That's all, stop editing!. Everything you add must go above it. WP-CLI uses this same line as its default anchor for new settings, which tells you it is the intended spot.

This line turns off the plugin and theme code editors for every user on the site.

define( 'DISALLOW_FILE_EDIT', true );

Save the file. You should see no change on the front of your site. The change only shows inside the dashboard.

Quick tip: search the file for DISALLOW_FILE_EDIT before you add it. If the constant is already defined, change the existing line instead of adding a second one, so there is only one place that decides the value.

Step 3b: Or set it with one WP-CLI command

If you have SSH and WP-CLI, you can skip manual editing. This command adds the constant to wp-config.php, or updates it if it already exists.

wp config set DISALLOW_FILE_EDIT true --raw

The --raw flag writes the PHP boolean true instead of a quoted string. Use it so the generated setting matches WordPress's documented boolean constant. A non-empty string such as 'true' is truthy in PHP, so quotes alone do not explain an editor that remains visible.

You should see a line that begins with Success: saying the constant was added or updated. By default, WP-CLI places new values just before the "That's all, stop editing!" line, which is exactly where you want them.

Decide whether to lock file changes too

DISALLOW_FILE_MODS is the bigger switch. The WordPress wp-config.php reference says it "will block users being able to use the plugin and theme installation/update functionality" in the admin area. It also says that setting it "also disables the Plugin and Theme File editor," so you do not need both lines, although having both is harmless and makes your intent clear.

Who should use it

It suits sites where updates already happen through a deployment process, SSH, or a developer who manages the code. It also suits sites that rarely change and where you would rather be the only person who adds code.

It does not suit a site where a non-technical owner clicks Update in the dashboard every week and has no other way to update. Turning it on there means updates quietly stop.

Why this matters: the reference page treats core updates separately, in its own section on disabling WordPress core updates. This constant is about plugins and themes. Plan as if plugin and theme updates from the dashboard will no longer work, and check what your own site does after you switch it on.

If automatic updates are part of your current plan, read our guide to safe auto-updates with a backup plan before you change anything, so the two setups do not fight each other.

Step 4: Add DISALLOW_FILE_MODS

This line blocks installing, updating and editing plugins and themes from the dashboard. Put it next to the first constant, above the "stop editing" line.

define( 'DISALLOW_FILE_MODS', true );

The WP-CLI version does the same thing in one command.

wp config set DISALLOW_FILE_MODS true --raw

You should see a Success: line, and in the dashboard the options to add new plugins and update existing ones should be blocked.

Step 5: Set up your manual update route

You now need a way to update that does not use the dashboard. With WP-CLI, this command first shows which plugins have updates, without changing anything.

wp plugin update --all --dry-run

If the list looks right, this command updates all plugins that have updates.

wp plugin update --all

The WP-CLI documentation for wp plugin update does not mention DISALLOW_FILE_MODS, so test this on your own server. If the update is refused while the lock is on, use a short maintenance window: switch the lock off, update, and switch it back on.

These three commands turn the lock off, run the updates, then turn the lock on again.

wp config set DISALLOW_FILE_MODS false --raw
wp plugin update --all
wp config set DISALLOW_FILE_MODS true --raw

Without SSH, the manual route is uploading the new plugin or theme version over SFTP, or briefly changing the line to false in File Manager, updating in the dashboard, and changing it back.

Quick tip: put the "switch it back on" step in your calendar or your update checklist. A lock that someone forgot to put back is not a lock.

Made-up example: Priya runs a small bakery site. A freelancer she worked with last year still had an admin account, and his laptop was later stolen. Someone logged in with his saved password and opened the plugin editor to paste in hidden spam links. On her second site, where she had set DISALLOW_FILE_EDIT months earlier, the same stolen login found no editor at all, so the attacker had to try something else, and Priya had time to notice the strange login and remove the old account. The lock did not make the site safe on its own, but it removed the easiest path.

Protect wp-config.php itself

Locking the editor is half of the job. The file that holds the lock should also be hard to read and hard to change.

Step 6: Tighten wp-config.php permissions

Permissions are the Unix rules for who can read, write or run a file. The hardening handbook says to make sure "only you (and the web server) can read this file (it generally means a 400 or 440 permission)." A value of 400 means only the owner can read it. A value of 440 means the owner and the owner's group can read it, and nobody can write to it.

This command sets wp-config.php to owner read only.

chmod 400 wp-config.php

If your site breaks after that, the web server probably runs as a different user that needs group read access. This command allows group read as well.

chmod 440 wp-config.php

In cPanel File Manager, select the file, click Permissions in the toolbar, enter the value, and save.

Heads up: with 400 or 440, nobody can write to the file, including you and WP-CLI. When you need to change it later, set it to 600 for a moment, make the change, then set it back.

For the rest of the install, the handbook gives 755 for folders and 644 for files. These two commands apply those values to the whole WordPress folder. Replace the path with your real install path.

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;
find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Run the wp-config.php command again afterwards, because the second find line resets it to 644. For plugins, the handbook says "all files should be writable only by your user account." If you want the deeper version of this, including what to do after a break-in, see how to harden WordPress file permissions after a PHP RCE.

Step 7: Block web requests to wp-config.php on Apache

On servers that read .htaccess files, such as Apache, you can tell the server never to serve wp-config.php over the web. Back up .htaccess first, the same way you backed up wp-config.php in Step 1.

This block, from the WordPress hardening handbook, denies every web request for the file. The handbook says to put it at the very top of .htaccess.

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

The Apache documentation describes Require all denied as "Access is denied unconditionally." It mimics what the older Deny from all directive did.

If your site runs on Nginx or another server that ignores .htaccess, this file does nothing there. Ask your host or developer to add an equivalent rule in the server configuration.

What about moving wp-config.php one folder up?

The handbook says WordPress can find wp-config.php one directory above the install. How much this helps depends on your setup. If your host already places the site in a folder like public_html, moving it one level up keeps it out of the web root, but it also confuses some tools and backup plugins. If you are unsure, keep the file where it is and rely on permissions and the deny rule.

Step 8: Keep debug.log out of reach

While you are in wp-config.php, look for WP_DEBUG_LOG. The reference page says "the default debug log file is /wp-content/debug.log" and warns that "placing error logs in publicly accessible locations is a security risk." Error logs can reveal file paths and plugin names.

The page recommends keeping logs above the public root, or at least setting the log file to 600. It also gives this .htaccess block to stop anyone reading the log over the web.

<Files debug.log>
  Order allow,deny
  Deny from all
</Files>

That block uses the older Apache syntax. On Apache 2.4, the equivalent with the newer directive looks like this.

<Files "debug.log">
Require all denied
</Files>

For the full routine, see how to use the WordPress debug log safely after an update.

How to check it worked

Do these checks right after the change, while you still remember what you did.

• Dashboard check: log in as an administrator and look in the admin sidebar for the Theme File Editor and Plugin File Editor entries. Opening them should no longer give you a code editor that can save changes.
• Updates check, only if you set DISALLOW_FILE_MODS: look at the plugin screens in the admin sidebar. The options to add new plugins and run updates should be missing or blocked.
• WP-CLI value check: run wp config get DISALLOW_FILE_EDIT. You should see true.
• WP-CLI truth check: run wp config is-true DISALLOW_FILE_EDIT and then echo $?. A result of 0 means the constant is set to a true value.
• Permission check: run ls -l wp-config.php. The start of the line should read -r-------- for 400 or -r--r----- for 440.
• Web check for the deny rule: run curl -I https://example.com/wp-config.php with your own domain. With the Apache rule in place, you should get a 403 status, which means forbidden.

Troubleshooting

The site shows a blank page or a server error right after saving

Likely cause: a typo in the new line, such as a missing semicolon, a curly quote pasted from a word processor, or the line placed below the "stop editing" comment. Fix: restore your backup from Step 1, then add the line again by typing straight single quotes and ending with ;.

The editor is still in the admin sidebar

Likely cause: WordPress is loading a different wp-config.php, or an earlier definition sets DISALLOW_FILE_EDIT to false. Run wp config path to see which file WP-CLI uses, inspect that file for duplicate definitions, and ensure one definition sets the PHP boolean true before WordPress loads its settings. PHP constants cannot be redefined, so a later duplicate does not repair an earlier value. Sign out and back in before rechecking the built-in editor.

WP-CLI says it cannot write to wp-config.php

Likely cause: you already set the file to 400 or 440, so nobody can write to it. Fix: run chmod 600 wp-config.php, run your wp config set command again, then set the permissions back to 400 or 440.

The site stopped loading after chmod 400

Likely cause: PHP runs as a different user from the file owner, so it can no longer read the file. Fix: try chmod 440 wp-config.php. If that still fails, set it back to 644 and ask your host which permission they recommend for their setup.

A plugin shows errors or missing screens after the change

Likely cause: the WordPress reference warns that plugins which check current_user_can('edit_plugins') may be affected, because that capability is removed. Fix: check whether the plugin has an update or a setting that does not depend on file editing. If not, contact the plugin author and mention DISALLOW_FILE_EDIT by name.

Plugin updates stopped and nobody noticed

Likely cause: DISALLOW_FILE_MODS is on and the manual route from Step 5 was never put into practice. Fix: run wp plugin update --all --dry-run to see what is waiting, update now, and add a fixed day in your calendar for future updates.

Security notes and when to ask for help

The editor lock works best next to a few other habits. Remove admin accounts you no longer need, use two-factor login for every administrator, and review new plugins before you install them. Our WordPress plugin supply chain audit with WP-CLI is a good next read if you manage several sites.

Ask your host for help if you cannot find wp-config.php, if the site runs on Nginx and you need the deny rule, or if permissions behave differently from what this guide describes. Ask a developer if a plugin your business depends on breaks when the editor is locked.

But what if you need to make a quick fix to a theme file later? Edit the file over SFTP or in your host's file manager, after taking a copy. That is safer than the dashboard editor anyway, because you keep a backup and you can undo a mistake without needing a working site.

The one message worth forwarding

Copy this to the person who looks after your site.

Hi, could you please make these changes on our WordPress site this week?
1. Back up wp-config.php and .htaccess to a folder outside the web root.
2. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php above the "That's all, stop editing!" line.
3. Tell me whether we should also add DISALLOW_FILE_MODS, and if yes, how plugin and theme updates will be done from now on.
4. Set wp-config.php permissions to 400 or 440, whichever works on our server.
5. If we run Apache, add the <Files "wp-config.php"> Require all denied </Files> block at the top of .htaccess.
6. Confirm the theme and plugin editors are gone from the dashboard.
Thanks!

Locking the file editor takes one line and a backup, and it closes the easiest door a stolen admin password would otherwise walk through.