DISALLOW_FILE_MODS: restore WordPress updates according to site policy

Recognize a prohibition on modifying files

The site works, but buttons for installing or updating a plugin have disappeared, or WordPress says that file modifications are not allowed. The DISALLOW_FILE_MODS constant may explain this situation. A constant is a configuration value loaded by PHP: it cannot be changed through a dashboard button.

The goal is to restore an operational maintenance process. Depending on how the site is organized, this will be WordPress administration or deployment prepared elsewhere. Making a button reappear is not enough if the deployment system subsequently replaces the files, or if nobody takes responsibility for updates after recovery.

However, no new versions appearing in the list does not prove this restriction exists. Start by noting exactly what is missing: the Add New menu, update link, notification, or only the file editor. A download failing after it starts represents a different stage. This distinction avoids changing a security policy to solve an unrelated connection failure.

Check the site and account before configuration

This procedure mainly concerns self-hosted WordPress when you have authorized file access. On WordPress.com, capabilities also depend on the service configuration and selected site. A plan or account limitation cannot be repaired by looking for a configuration file you cannot access.

In a multisite network, subsite and network administration do not offer the same capabilities. A local administrator may manage content without being able to install plugins for the network. Therefore compare expected permissions with those of the account actually logged in before concluding that a technical lock exists. The network configuration file may be shared by every site: a change is not limited to the subsite whose tab is open. Involve the network administrator before editing this shared policy.

1. Record the exact administration address and the site name displayed in the top bar.
2. Check with the owner that the account has the expected maintenance permissions. For a network, request verification in network administration.
3. Open Plugins, Appearance, then Dashboard > Updates, and note which commands are present or absent.
4. Keep the precise message and its date. If another authorized administrator sees the commands on the same site, first examine the affected account’s permissions.

Prepare a recoverable change

A wp-config.php file usually contains database connection information and security secrets. Its backup must remain in a private location outside the directory served to visitors. Do not create a copy named wp-config.php.bak beside the public file: incorrect server configuration could allow it to be downloaded.

Keep a file-access session open during the intervention. If a syntax error prevents WordPress from starting, this access lets you restore the file without relying on the dashboard. Also prepare a consistent file and database backup before subsequently installing an actual update; backing up only the changed line cannot undo the effects of an upgraded plugin.

On a working copy, disable emails, payments, and integrations capable of producing real effects. Checking the restriction requires neither a commercial operation nor a form submission. Choose a time when nobody else is replacing configuration, and record the initial value and the person responsible for maintenance.

Find the definition actually used

Open files through SFTP or the file manager provided for the correct domain. The wp-config.php file is usually at the WordPress file root; some architectures place it elsewhere or make it load additional configuration. The directory containing media is therefore not enough to identify the active configuration.

Search for the exact text DISALLOW_FILE_MODS in the file and in configuration files it explicitly includes. Also record nearby comments: they may indicate a value generated by hosting or a deployment process. A line found only in documentation, a comment, or an old backup defines nothing for the current site.

1. Confirm the domain path in the hosting panel, then open its configuration for reading.
2. Search for the exact constant name without copying the rest of the file into a public message.
3. Note whether the value is the boolean true, the boolean false, or an expression coming from an environment.
4. Identify the file’s owner. If it is generated, find the setting or source file producing it before making any change.

Correct a constant added to your own file

This approach is appropriate if you own the configuration, the site should be maintained through WordPress, and you have identified a local definition added intentionally or by mistake. It is not appropriate for hosting that requires a separate deployment process. Confirm this before changing the value.

In the active wp-config.php, replace only the existing definition with the example below. This is a line to correct, not a complete file to paste. Use PHP booleans without quotes. Do not add a second definition farther down: an already-defined constant does not become changeable because another line repeats its name.

Before lifting the restriction, check two broader effects. It also blocks theme and plugin file editors: if those editors must remain prohibited, retain or have DISALLOW_FILE_EDIT separately defined as true in the authorized source, without duplicates. Also check the automatic-update policy before the change, because that mechanism may become eligible again.

The word false in quotes is not the expected boolean: PHP treats this nonempty string as true. If the value comes from an environment variable or expression, have its conversion corrected in the managed source. Do not replace all that logic with a fixed value without understanding the other environments it configures.

1. Download the current version to the prepared private location and retain its permissions.
2. Replace true with false in the single relevant definition, before wp-settings.php loads.
3. Save the file as PHP text, retaining its name and encoding, then transfer it if necessary.
4. Reload a public page and administration. If a PHP error appears, immediately restore the initial copy through the same file access.

define( 'DISALLOW_FILE_MODS', false );

Check what the change actually allowed

The first expected result is the return of commands authorized for the account used. Their presence indicates that this restriction no longer hides them; it guarantees neither compatibility of the next version nor actual disk writing. Do not update every plugin to measure this result.

This setting applies to the installation, not just the open tab or your session. After changing it, confirm that automatic updates and file editors remain consistent with the previously defined policy. The return of manual commands must not be the only check.

1. Reopen Plugins and Dashboard > Updates with the identified maintenance account.
2. Compare commands with your initial record and document the difference.
3. Examine automatic-update choices for the affected components and the file-editor restriction, without opening the editors to modify code.
4. Separately prepare a compatible update on a copy, with a backup and rollback.
5. If nothing changes, do not add more definitions: check the active file and continue to the managed policy or filter.

Retain the restriction when deployment manages the site

On a site managed by an agency, host, or code repository, missing commands may be intentional. Files delivered to production must then remain identical to a prepared and validated version. Changing a plugin directly in WordPress would create a difference that could disappear at the next deployment.

The solution is to use the intended maintenance procedure. This does not mean abandoning the update: it is performed in the right place, then delivered to the site. There is no universal menu for this process; use the project and panel actually associated with your installation. A command found for another platform is not a valid procedure for yours.

1. Record the component’s installed and target versions, along with the reason for updating.
2. Open the maintenance project identified in your contract or internal procedure and create a request for that specific component.
3. Have the new version prepared in the intended validation environment, with sensitive data and external effects controlled.
4. Check the affected functions, then use the documented deployment process for production.
5. Verify the delivered version in WordPress. Retain the restriction if it is part of this organization and document how to return to the previous release.

Read a single value with WP-CLI when the context is controlled

If you already have access to the hosting terminal and WP-CLI, a targeted read can complement file inspection. This approach remains optional: you do not need to install a new tool on the server to correct an identified line. Use the technical account and installation path validated by the administrator.

The command below requests only this constant’s value. It runs before normal WordPress loading but evaluates the configuration’s PHP: it is not merely a text search. Reserve it for known, trusted configuration. If its contents are suspicious or its custom loading is unknown, prefer private file inspection with the maintainer.

Replace the quoted path with the WordPress files’ path; the quotes preserve any space in the path. JSON format distinguishes the boolean false from the text "false". The first does not block modifications through this constant; the second is a string interpreted as true. A true response confirms a true value in this terminal context, not yet the sole cause of every missing menu.

The terminal may receive environment variables different from those of the web process. Included files and configuration conditions must therefore be understood before generalizing its result to the dashboard. A missing result or error does not prove everything is allowed. Keep the redacted message and return to the targeted read; do not run a write command or a complete constant list, which would expose unnecessary secrets.

wp config get DISALLOW_FILE_MODS --type=constant --format=json --path='/chemin/vers/wordpress'

Examine a filter if the constant does not explain the block

WordPress consults more than the constant. The wp_is_file_mod_allowed() function also passes its decision to the file_mod_allowed filter. A filter is a point where a plugin or custom code can adjust behavior. A false value in your file therefore does not require every component to accept modifications.

The investigation must target the responsible code without randomly removing site protections. If administration is accessible, look under Plugins at active items and, where available, the must-use category. Host-managed components may not offer an ordinary deactivation button. Their presence alone does not prove they cause the rejection.

Ask the maintainer to find registration of the file_mod_allowed filter in files actually loaded and identify its condition: production environment, user, or operation. Core provides, among others, capability_update_core for installation and update capabilities and automatic_updater for the automatic mechanism. The first context’s name therefore does not mean it protects only core. A policy may act differently depending on the procedure. Correct its source setting, then verify the affected action; a filter that always forces permission would conceal the original decision.

Do not confuse other constants with this prohibition

DISALLOW_FILE_MODS also covers file editors. Conversely, DISALLOW_FILE_EDIT targets those editors without by itself prohibiting installations and updates. If only the editors are missing, they do not need to be restored for normal component maintenance. Keeping this prohibition separate preserves the intended protection.

AUTOMATIC_UPDATER_DISABLED concerns the automatic mechanism. Do not delete it merely because a manual operation fails. Likewise, the core automatic-update setting does not replace checking the general permission to modify files. Identify the operation actually expected before touching these values.

Finally, WP_HTTP_BLOCK_EXTERNAL controls outbound requests. A rejected connection to WordPress.org requires a different diagnosis from a disappearing button. Do not replace it with general communication permission without examining the existing restriction. When several constants are present, separately record their function and owner. Changing four values at once prevents you from knowing which was useful and may open capabilities nobody requested.

Handle an FTP prompt or write error separately

After correcting the policy, WordPress may request FTP credentials or report that a directory cannot be created. This new message does not mean the constant was incorrectly fixed. The application has reached another stage: it is now trying to access files and encountering a transport, ownership, or permissions issue.

Keep the exact message and the cited directory path. Check that it belongs to the current site and find the procedure for that particular failure. Do not automatically add FS_METHOD to force direct writing or grant 777 permissions. Overly broad permissions fix neither a WordPress policy nor incorrect file ownership.

Installing a troubleshooting plugin is not relevant for lifting this lock. If installations are prohibited, the tool itself may be impossible to add; and an ordinary tool cannot make an already-loaded constant changeable. The approach without a new plugin is most direct here. If an already-installed management component controls the policy, its documented setting may help, but only after identifying its exact role.

Roll back without undoing other interventions

If the modified file causes an immediate failure, restore its initial private copy through the file-access session left open. Then check the homepage and administration login. Do not restore the entire site for a simple character error if no other changes have occurred since the backup.

If the site works but the chosen policy must be restored, restore only the previous definition in the source actually used. Account for any intervening changes: replacing an old complete file could erase legitimate new configuration. Check differences before any transfer.

1. Record the reason for rollback and the time of the last change.
2. Restore the appropriate line or file according to the actual scope of the change.
3. Reload the screens observed initially and compare available commands.
4. If an update has already run, handle its rollback separately: restoring the constant does not restore old files or the old database.
5. Store evidence of the result with the maintenance procedure, then remove any working copy left in a public location.

Keep an explicit maintenance policy

After resolution, document the configuration path, chosen value, person managing it, and process for future updates. A short comment in the internal procedure is more useful than a constant whose origin nobody knows. For generated configuration, emphasize the source setting: manually correcting the produced file risks being lost.

Also establish who checks new versions and how an urgent update will be delivered. A write prohibition can be consistent with organized maintenance; it becomes problematic if it leaves the site without anyone responsible over time. Conversely, allowing modifications replaces neither backup nor compatibility validation.

To hand over an unresolved problem, provide the administration address, missing commands, account role, redacted definition, and its location. Add the targeted-read result if you performed it, along with the existence of any managed deployment. These details let the maintainer distinguish an intentional restriction from an unexpected filter without requesting your complete configuration file or secrets.

Choose between permissions, the constant, and the deployment process

Three observations lead to different actions.

After the fix, compare four elements: manual installation, manual updates, automatic updates, and file editors. They do not all need to be enabled for normal maintenance. For a site administered through WordPress, allowing updates while keeping the code editor prohibited may be consistent. Record who will handle the next update and its rollback: recovering a button without a maintenance owner solves only part of the problem.

1. A second authorized administrator sees commands on the same site, but your account does not: have capabilities and multisite scope examined. Changing the shared constant does not repair a local assignment.
2. No maintenance account sees the commands, and the active configuration defines DISALLOW_FILE_MODS as true: identify the owner of that policy. If WordPress should manage updates, correct the single definition; if deployment manages them, use that deployment process.
3. The constant is false but the rejection persists: examine the file_mod_allowed filter and web-process configuration. The terminal reading alone does not establish the domain’s state.