If you searched for disable file editing wordpress, the safest general approach is to back up the site and set DISALLOW_FILE_EDIT to true in wp-config.php. You can also apply the equivalent hardening control through a trusted security plugin. This removes the built-in Theme File Editor and Plugin File Editor from the WordPress dashboard; it does not delete your files or disable SFTP, SSH, a hosting File Manager, Git, or local development.
For broader context, see this guide to WordPress security.
TL;DR: Back up your complete site before changing the configuration. Then set DISALLOW_FILE_EDIT to true or apply the same control through a trusted security plugin, and verify both editors are gone. For related file-hardening precautions, see BlogVault’s wp-config.php security guide.
What the setting does
WordPress’s dashboard editors let an administrator change PHP in an active theme or plugin. Those changes are applied to the live site immediately. The official WordPress file-editing documentation recommends backups and explains that the editors are a convenience feature, not a required part of normal site operation.
If an attacker takes over an administrator account, the editor can turn dashboard access into a direct way to alter PHP. The attacker could inject malicious code, create a backdoor, deface the site, or break an important feature. A legitimate administrator can also save valid PHP in the wrong place or use code that behaves badly in the current theme or plugin context.
Disabling the editor limits one post-compromise route and prevents accidental live-code edits. It does not prevent the account takeover, repair vulnerable software, block malicious uploads, or clean an infected site. WordPress’s hardening guidance describes the setting as a way to remove the dashboard’s file-editing capability, not as a complete security solution.
Check whether file editing is enabled
The menu location depends on the theme and WordPress version:
- With a classic theme, look for Appearance > Theme File Editor and Plugins > Plugin File Editor.
- With a block theme, WordPress lists both editors under Tools.
The labels may vary. If you cannot find an editor, it may already be disabled by DISALLOW_FILE_EDIT, hidden by a security plugin or hosting configuration, or unavailable to your user account. A missing menu is a useful clue, but it does not identify which control removed it.
Back up before changing anything
Before editing wp-config.php, take a reliable WordPress backup that includes the database and site files. Keep a separate copy of the original configuration file and know how to restore it through your host or another file-access method. A typo, misplaced line, or edit to the wrong setting can produce a PHP error or make the dashboard unavailable.
🛟 Note: A backup is useful only if it can be restored. Check when it was created, confirm that it includes both the database and files, and identify the host or backup tool’s restore procedure before you edit the configuration.
Method 1: Edit wp-config.php
This is the direct WordPress method. Use it only when you can identify the correct site and have safe access to its files.
1. Open the correct WordPress installation
Use SFTP, FTP, your hosting File Manager, or SSH to reach the directory that contains the site’s wp-config.php. If access behaves unexpectedly, check the WordPress file permissions before changing the file. The directory is often named public_html, but it can be a subdirectory or a different document root. Confirm the domain, staging status, and site path before editing because a hosting account can contain several WordPress installations.
SFTP is preferable to unencrypted FTP when your host supports it. If you use a File Manager, download or copy the original file first. Never put real passwords, server addresses, or private access details in screenshots or examples.
2. Search for an existing definition
Open wp-config.php in a plain-text editor and search for DISALLOW_FILE_EDIT. If you need more context on wp-config.php database settings, review it before changing the file. If the constant already exists, change its value to true rather than adding another definition:
define( ‘DISALLOW_FILE_EDIT’, true );
Non-live planning fixture: the single DISALLOW_FILE_EDIT definition appears before WordPress loads.
If the constant does not exist, add this line with the other configuration definitions. Put it before the line that loads WordPress, such as require_once ABSPATH . ‘wp-settings.php’;. Do not put it after WordPress has started loading.
Search first. Adding the same constant twice can create a duplicate-definition warning. A resolved WordPress.org support case records this problem when a plugin-managed setting writes a second definition. If a security plugin already manages the setting, use that plugin’s control or edit the existing line instead of adding a competing one.
⚠️ Note: Do not “fix” a duplicate by adding a third line or by placing the new line at the bottom of the file. One clear definition in the configuration section is easier to audit and avoids conflicting values.
3. Save and upload the file
Save the file as plain text and upload it to the same WordPress directory if you edited a downloaded copy. Do not change the file name or surrounding PHP syntax. With a File Manager or SSH editor, make the same change before the WordPress load statement, save it, and close the editor. The access method changes; the WordPress setting and its placement do not.
🔐 Note: SFTP is preferable to traditional FTP when both are available because it protects the file transfer with an encrypted connection. If you are unsure which directory belongs to the live site, stop and ask the host rather than editing the first
wp-config.phpyou find.
For complementary controls, harden your WordPress site beyond this editor setting.
Method 2: Use a security plugin
A trusted WordPress security plugin can be simpler for a site owner who does not normally manage server files. After making a backup, open the plugin’s security or hardening controls, find the setting for disabling the WordPress file editor, enable it, and save. Refresh the admin area and verify both editor locations afterward.
If your current MalCare dashboard provides this hardening control, it can apply the protection without requiring you to edit wp-config.php yourself. Treat the exact MalCare menu names, account or sync steps, and plan availability as version-dependent; verify the current dashboard before publishing product-specific instructions or screenshots. MalCare’s scanner, firewall, monitoring, and cleanup capabilities address separate risks. They are not effects of DISALLOW_FILE_EDIT.
The plugin route trades manual configuration work for a dependency on the plugin’s settings and implementation. If that tradeoff fits your workflow, MalCare security for WordPress is one option to evaluate. Keep a manual recovery option available, and confirm the result rather than assuming that a saved setting changed the site.
🧭 Note: A plugin is a good fit when you do not have safe server-file access, but it should not become the only recovery path. Keep a current backup and make sure an authorized person can still reach the site through the host if the plugin or dashboard becomes unavailable.
Verify the change
After saving the setting or applying it through a plugin:
Non-live planning fixture: both dashboard editor links are absent while other file-access methods remain available.
- Refresh the WordPress admin area.
- Check the locations for both Theme File Editor and Plugin File Editor.
- Open the homepage and one important site function.
- Log in again or complete a routine admin task, such as editing a post.
A successful change removes the two dashboard editor links while leaving the public site, content, plugin settings, and server-side file access available. If the editor links remain, check that you edited the correct installation, that the existing constant is set to true, and that a plugin, host rule, or user permission is not affecting what you see.
Non-live planning fixture: the public site and a routine admin task remain available after editor hardening.
✅ Note: Check both editor locations, not just the menu you normally use. A classic theme and a block theme can expose the links in different places, and a missing link by itself does not prove that
DISALLOW_FILE_EDITis the control in effect.
Recover from an error
If the site shows a PHP error, blank page, or unexpected warning after the edit, restore the original wp-config.php from your backup or use the host’s File Manager, SFTP, or SSH access to correct the line. Common causes include a typo, incorrect placement, a second definition, or an edit made to another site’s configuration file.
If the dashboard is unavailable, WP Remote’s WordPress site recovery guide covers host-level recovery with both file and database backups.
Do not repeatedly re-enable the editor just to make a quick live change. If you must enable it for planned maintenance, change the existing value to false during a controlled window, complete the work, set it back to true, and verify both editor links are gone again.
🧯 Note: If you see a blank page or a PHP error, restore the known-good configuration first. Troubleshooting a live configuration edit is safer from the host’s file access or a backup restore than from a dashboard editor that may no longer be available.
Do not confuse file editing with file modifications
DISALLOW_FILE_EDIT disables the built-in theme and plugin editors. It does not block every way that files can change.
DISALLOW_FILE_MODS is broader. According to WordPress’s configuration documentation, it also blocks dashboard plugin and theme installation and update functions, in addition to disabling the editors. That can interfere with a site’s normal maintenance and update process.
Use DISALLOW_FILE_EDIT when the goal is editor-only hardening. Consider DISALLOW_FILE_MODS only when the team deliberately wants to block dashboard installs and updates and has a separate deployment process. WordPress does not provide a normal built-in switch for disabling only the theme editor or only the plugin editor.
🧩 Note:
DISALLOW_FILE_MODScan turn a security decision into a maintenance problem. If dashboard updates are part of your team’s normal process, document the replacement deployment and update path before choosing the broader constant.
Use a safer workflow for future code changes
Removing the live editor works only if the team has another way to make and recover code changes:
- Test changes on a WordPress staging environment or local copy before touching production.
- Use a child theme or another update-safe theme customization method instead of editing a parent theme directly.
- Use a maintained custom-code workflow for small PHP additions, and review and test each snippet.
- Deploy approved files with SFTP, SSH, or Git rather than editing live PHP in the dashboard.
- Keep a recent backup and document who can restore the site.
If you do not have safe file access, ask your host or developer to apply the setting, or use a reputable security plugin. Do not re-enable a live editor simply because it is the fastest available path.
🧪 Note: For a small PHP change, test the code on a staging copy or local site first, then deploy the approved version. A valid PHP snippet can still be wrong for a particular theme, plugin, hook, or WordPress configuration.
Keep the security boundary clear
Disabling file editing is one hardening measure. Follow a WordPress security maintenance checklist: keep WordPress, plugins, and themes updated; limit administrator access; use strong unique passwords and two-step login; and keep backups that you have actually tested. A firewall or monitoring service addresses other parts of the threat model.
If you suspect the site is hacked, missing editor links do not prove that it is clean. Preserve a backup, review the affected account and recent file changes, and use file integrity monitoring alongside a malware detection and cleanup process when the evidence points to an infection. The setting reduces possible damage after a breach; it does not replace incident response.
🚨 Note: Treat a suspected compromise as an incident, not as a file-editor setting problem. Preserve evidence and use a trusted cleanup or recovery process; changing this one constant will not remove a backdoor that is already on the server.
Conclusion
For most WordPress sites, disabling file editing is a sensible damage-limitation step, not a complete security strategy. Back up the site, set DISALLOW_FILE_EDIT to true in the correct wp-config.php file or apply the equivalent trusted-plugin control, and confirm that both dashboard editors disappear.
The tradeoff is a safer maintenance process: make code changes on staging or locally, deploy them through SFTP, SSH, or Git, and keep a tested rollback path. A WordPress security maintenance checklist can help keep that process consistent.
