wp-config.php Key Constants Explained: What WP_DEBUG, DISALLOW_FILE_EDIT, and WP_MEMORY_LIMIT Actually Do

Ask most people where WordPress settings live, and they’ll point to the admin dashboard’s Settings menu. But a specific category of settings — the ones that determine how the site starts up in the first place — don’t live there at all. They’re written directly into a PHP file called wp-config.php, using define(). There’s a reason for that split. Dashboard settings are stored in the database (the wp_options table) and get read only after WordPress itself has finished booting. wp-config.php, on the other hand — which also holds the database connection details — is read before WordPress boots. So anything that shapes the boot-time conditions themselves — where the database is, whether debug output is on, whether files can be edited from the browser — has nowhere else to go but here.

Note: define('CONSTANT_NAME', value) is PHP syntax for registering a value that won’t change for the rest of the program’s execution. Once defined, any file can read the same value. WordPress core checks for these constants with defined('CONSTANT_NAME') throughout its codebase and adjusts its behavior accordingly.

WP_DEBUG / WP_DEBUG_LOG / WP_DEBUG_DISPLAY — Three Separate Switches

The debug-related constants number three, and their similar names make them easy to conflate.

• WP_DEBUG — the master switch for detecting PHP warnings, notices, and deprecated-function usage. Setting it to true is what makes the other two constants meaningful in the first place
• WP_DEBUG_DISPLAY — whether detected errors get printed to the screen. Leave this true on a production site and visitors see raw PHP warnings staring back at them
• WP_DEBUG_LOG — whether detected errors get written to wp-content/debug.log. If you want errors recorded to a file without showing anything on screen, this is the one to enable while keeping WP_DEBUG_DISPLAY off

The combination that shows up most often in practice keeps visitors seeing nothing while still leaving a trail for developers to check later:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Worth flagging: in an environment where WP_DEBUG_LOG was never turned on, wp-content/debug.log never gets created in the first place. “Something is clearly failing, but there’s no log file anywhere” almost always traces back to checking this constant first.

As a working example, this app’s recovery logic (fetch_recovery_logs() in core/ssh_utils.py) tails wp-content/debug.log over SSH whenever a post-update HTTP check comes back with a 5xx status, scanning the tail for a wp-content/plugins/<plugin-name>/ path pattern to identify which plugin threw the fatal error, then deactivates just that plugin. For this recovery path to work at all, the target site needs WP_DEBUG_LOG enabled — meaning debug.log is actually being written. On a site where that file doesn’t exist, the lookup comes up empty and the logic falls back to reading the server’s generic error_log instead. Whether logging is switched on directly determines whether a fatal error can be diagnosed automatically after the fact.

WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT — Two Layers of Memory Ceiling

PHP already has a server-wide memory_limit setting, but WordPress adds a second, tighter ceiling on top of it.

• WP_MEMORY_LIMIT — the memory available to normal front-end rendering and typical processing
• WP_MAX_MEMORY_LIMIT — a higher ceiling reserved for admin-side work that briefly spikes memory use, like bulk plugin updates or large image processing

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Cross either ceiling and PHP kills the request outright with the familiar “Allowed memory size of X bytes exhausted” fatal error. That message isn’t a syntax error or a logic bug — it’s simply memory running out — and the underlying cause is frequently less “this plugin is broken” and more “the ceiling set here is too low for what this plugin needs.” Core and plugin bulk updates in particular tend to spike memory momentarily, which makes a memory-ceiling fatal one of the recurring reasons a maintenance tool that checks HTTP status after each step — like this one — sees a site come back with a 500 right after an update. Where the root cause is memory, not a broken plugin, the fix is raising WP_MEMORY_LIMIT (or the server-level memory_limit), not reinstalling anything.

DISALLOW_FILE_EDIT / DISALLOW_FILE_MODS — Blocking File Changes From the Dashboard

By default, the WordPress dashboard ships with a “Theme File Editor” and a “Plugin File Editor” — screens that let you edit PHP files directly from the browser. Convenient early in development, but on a site that’s already stable in production, it mostly just widens the attack surface for no operational benefit.

• DISALLOW_FILE_EDIT — removes both editor screens from the dashboard menu entirely
• DISALLOW_FILE_MODS — a stronger restriction: on top of removing the editors, it also blocks installing, updating, or deleting plugins and themes from the dashboard

define( 'DISALLOW_FILE_EDIT', true );

The detail worth remembering is that this constant only restricts file operations performed through the dashboard (wp-admin). Access via SSH or WP-CLI, which reaches the server’s filesystem directly, is unaffected. In practice, SSH/WP-CLI-based maintenance workflows — including this app’s — run every core, plugin, and theme update as a WP-CLI command on the server side and never touch the dashboard’s file editor to begin with. Turning on DISALLOW_FILE_EDIT costs nothing operationally in that setup, and closes off one path — unintended file edits through the dashboard — that the workflow was never using anyway.

Summary

None of these constants look like much on their own, but together they decide things that matter the moment something goes wrong during maintenance: whether a log trail exists to diagnose a fatal error, whether an update fails from running out of memory, and whether files can be changed straight from the dashboard. Checking what this file actually contains before diving into troubleshooting tends to narrow things down faster than most other starting points.