DISALLOW_FILE_MODS vs DISALLOW_FILE_EDIT: what each one blocks

Two constants for wp-config.php have names one word apart, and hardening checklists often list them side by side as if they did the same thing. They don’t. DISALLOW_FILE_EDIT takes the code editors out of the dashboard. DISALLOW_FILE_MODS stops the dashboard changing code files at all, and that includes updates.

Pick the wrong one and you either leave open the door you meant to close, or you stop security updates without noticing. This guide covers what each constant does, the catch that comes with DISALLOW_FILE_MODS, and how to choose.

The short answer

Both go in wp-config.php, above the line that says to stop editing. Both apply to every user, administrators included. Neither can be switched off from the dashboard: undoing either one means editing that file again.

What DISALLOW_FILE_EDIT does

define( 'DISALLOW_FILE_EDIT', true );

WordPress ships with two code editors inside the admin. The Theme File Editor sits under Appearance, or under Tools on a block theme. The Plugin File Editor sits under Plugins, or under Tools on a block theme. Both let anyone with an administrator account open a theme’s or plugin’s PHP files in a browser tab, change them and save.

That is a lot of reach for a text box. A stolen administrator session is one edit away from running any PHP it likes on your server. And an honest typo saved into a theme’s functions.php can take the site down.

With DISALLOW_FILE_EDIT set, WordPress refuses the three capabilities the editors need: edit_themes, edit_plugins and edit_files. Core maps each of them to do_not_allow, which no user passes, super admins on a multisite network included. The two menu items disappear, and the editor screens refuse to load if someone types the address.

Nothing else changes. Installs, updates, deletions and activations all work as before.

This is the low-cost one. Most people who look after a WordPress site never use the built-in editors, and code changes are safer made in a real editor, with a backup or version control behind them. On almost any site, turning the editors off costs nothing.

What DISALLOW_FILE_MODS does

define( 'DISALLOW_FILE_MODS', true );

“File mods” means any change WordPress itself makes to plugin, theme or core files. Core checks the constant through a function called wp_is_file_mod_allowed(), and when the constant is set, the answer is no everywhere that function is asked:

• Installs and uploads are refused. The capabilities install_plugins, install_themes, upload_plugins and upload_themes are denied, so the Add Plugin screen, the theme installer and both Upload buttons go.
• Updates are refused. update_plugins, update_themes and update_core are denied, so updates can’t be applied from the dashboard.
• Deleting plugins and themes is refused, through delete_plugins and delete_themes.
• The file editors go too. The same capabilities DISALLOW_FILE_EDIT removes are denied here as well, so if you set DISALLOW_FILE_MODS, adding DISALLOW_FILE_EDIT changes nothing.
• Automatic updates stop. WordPress switches off its background updater entirely, so the core, plugin, theme and translation updates it would normally apply on its own don’t happen.
• Language packs can’t be installed or updated.

What still works: activating and deactivating plugins that are already installed, switching between themes that are already installed, and uploading media. Files in the uploads folder are not part of the constant’s reach.

The catch with DISALLOW_FILE_MODS

The constant doesn’t tell a new install from an update. Both are changes to code files, so both stop.

That has two consequences people tend to find out late.

Updates stop reaching the site. When a plugin you run ships a security release, the site doesn’t apply it, not automatically and not with a click. The minor WordPress releases that normally install themselves in the background stop as well. Unless someone updates the files another way, through a deployment, over SFTP or from the command line, the site stays on the old versions.

Only file access undoes it. The constant lives in wp-config.php. Turning it off means opening that file over FTP, SFTP, SSH or a hosting file manager. If the person running the site day to day has only a wp-admin login, which is the usual position after an agency hands a site over, they can’t apply an urgent update or install a plugin they need. They are stuck until someone with file access steps in.

None of that makes the constant wrong. On a site where every code change goes through a deployment pipeline, where plugins are managed with Composer or kept in a git repository and updates ship that way, the dashboard was never meant to change code, and DISALLOW_FILE_MODS makes that official. It is also a reasonable setting when your host applies updates for you. The trouble starts when it lands on a site that relies on the dashboard for its updates.

Which one to use

• You want the code editors gone. Use DISALLOW_FILE_EDIT. This suits nearly every site.
• All code arrives through deployments, and updates are handled there too. Use DISALLOW_FILE_MODS. It already covers the editors.
• You want to stop new plugins and themes being installed, and keep updates working. Neither constant does this. DISALLOW_FILE_EDIT doesn’t touch installs, and DISALLOW_FILE_MODS takes updates down with them. The way to get this split is to refuse the install capabilities and leave the update ones alone, which how to block plugin installs on a WordPress site covers step by step.

Setting both constants does no harm. It just adds nothing over DISALLOW_FILE_MODS alone.

How Adminkeep’s two switches compare

Adminkeep is a free plugin made of small features that each have one switch, and two of them cover the same ground as these constants, with one difference in approach: neither uses a constant. Both refuse capabilities while each request runs, so both can be switched off again from Settings → Adminkeep. Neither touches wp-config.php or changes the capabilities stored on a role.

Disable the theme and plugin file editor. On the settings screen this switch is called Disable File Editing. It refuses edit_plugins, edit_themes and edit_files, so the Theme File Editor and Plugin File Editor disappear, the same outcome as DISALLOW_FILE_EDIT. Installing, updating, activating and deactivating are untouched.

On a multisite network. The switch removes the editors for super admins too. On a network the plugin and theme editors live in Network Admin, which reads the main site’s settings, so the switch protects the network only when Adminkeep runs on the main site (network-activated, or activated there) with Disable File Editing switched on in the main site’s settings. If it is on only for a subsite, super admins keep the editors.

Block plugin and theme installs. On the settings screen this switch is called Installation Lockdown. It refuses install_plugins, install_themes, upload_plugins and upload_themes: nothing new from the WordPress.org directory, nothing from a ZIP file, and no replacing an installed plugin or theme by uploading a ZIP over it. Update notices, manual updates and automatic updates all keep working, activating and deactivating still work, and a plugin’s “View details” window still opens so you can read a changelog before updating. On a multisite network, super admins are not affected.

Switched on together, the two give you the part of DISALLOW_FILE_MODS that most sites want, no new code and no code edits from the dashboard, without stopping updates. And whoever has an administrator account can switch either one off again without file access.

Three limits, stated plainly:

• They work inside WordPress only. Like the constants, they govern what happens through the dashboard. FTP, SSH and WP-CLI are not affected, so anyone with file or server access can still change code.
• Reversible cuts both ways. Any administrator can switch them off from the settings screen, and that includes someone using a stolen administrator login. They guard against accidents and casual changes. Where a hijacked admin account is the risk you are planning for, a constant is the stronger choice, because the dashboard can’t undo it.
• They don’t override a constant. If DISALLOW_FILE_EDIT or DISALLOW_FILE_MODS is already set in wp-config.php, WordPress keeps enforcing it whatever the switches say. You can keep a constant and use the switches beside it; they don’t conflict.

To turn them on, go to Settings → Adminkeep and switch on Disable File Editing, Installation Lockdown, or both. There is nothing else to configure. If you don’t have the plugin yet, installation takes a minute, and the configuration docs describe every switch.