The built-in file editors in WordPress let an administrator change active theme and plugin code directly from the dashboard. That convenience also turns a compromised administrator session into an immediate code-change path and makes it easy to break a live site with an untested edit.
The correct way to disable those editors is to define DISALLOW_FILE_EDIT in /wp-config.php/. This removes the browser-based file editors while leaving normal server-side workflows such as SSH, SFTP, and deployment-based file changes untouched.
This setting only disables the in-dashboard editors. It does not disable the block-theme Site Editor under Appearance → Editor, and it does not block plugin, theme, or core installs and updates on its own. That broader write lock is controlled separately through DISALLOW_FILE_MODS and should be treated as a different policy decision.
$ cd /var/www/html $ grep -nE "DISALLOW_FILE_EDIT|DISALLOW_FILE_MODS" wp-config.php
No output means neither constant is defined yet.
If DISALLOW_FILE_EDIT is already set to true, the editor lock is already active.
If DISALLOW_FILE_MODS is set to true, the site is already under a broader policy that also blocks in-dashboard installs and updates. Do not replace that broader constant with DISALLOW_FILE_EDIT unless the deployment model has changed intentionally.
define( 'DISALLOW_FILE_EDIT', true );
Place the constant before /* That's all, stop editing! Happy publishing. */ so WordPress loads it with the rest of the site configuration.
$ grep -n "DISALLOW_FILE_EDIT" wp-config.php ##### snipped ##### define( 'DISALLOW_FILE_EDIT', true );
No web server restart is needed. WordPress applies the change on the next request.
On block-theme sites, both Theme File Editor and Plugin File Editor normally appear under Tools. On classic-theme sites, Theme File Editor normally appears under Appearance and Plugin File Editor under Plugins.
Appearance → Editor on a block-theme site is the Site Editor, which is a different feature and is not disabled by DISALLOW_FILE_EDIT.
If the menu items still appear after a reload, search for a second definition of DISALLOW_FILE_EDIT or a host-specific config include that overrides /wp-config.php/ later in the bootstrap process.
This change hardens the admin area against live browser edits, but it does not stop direct file changes made through shell access, file transfer tools, or deployment automation.