Advanced wp-config.php constants

How wp-config.php is structured

Every constant in wp-config.php must be defined before the line that reads `/* That's all, stop editing! */`. Once that line is reached WordPress stops applying overrides, so a constant placed after it is silently ignored. That single placement rule causes most of the cases where an administrator believes a setting was applied when it was not. If you are chasing a confusing site behaviour, the WordPress troubleshooting order article is the right lens for separating a config problem from a plugin or theme problem.

Memory and upload limits

The most commonly needed advanced constant is the PHP memory limit. By default WordPress sets WP_MEMORY_LIMIT to 40 MB on a typical install, which can be too low for a site running a page builder, WooCommerce or several plugins:

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

WP_MEMORY_LIMIT governs front-end page loads; WP_MAX_MEMORY_LIMIT governs admin operations such as media uploads, imports and plugin updates. Note that WordPress caps these at the PHP memory_limit set on the server when that value is lower, so raising the constants is pointless if the underlying PHP limit is the ceiling. The memory limit article walks through diagnosing that exact interplay.

Security switches

Two constants materially reduce the attack surface of an admin account that gets compromised:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

DISALLOW_FILE_EDIT removes the built-in Theme and Plugin file editors from the admin. Without it, a hijacked admin login can reach the Theme Editor and inject PHP straight into active files through the browser. DISALLOW_FILE_MODS goes further and blocks plugin, theme and core install and update actions from the admin entirely, which trades convenience for control and is a reasonable choice on a production site. Pair these with the security headers article for a stronger response to common attack vectors.

Debugging helpers

When you need to see what the site is actually doing, SAVEQUERIES records every database query and how long it ran:

define( 'SAVEQUERIES', true );

With that enabled the global $wpdb->queries array is populated per request, which debugging tools like Query Monitor display with timings and the calling function. It is a powerful diagnostic, but it keeps the full query log in memory on every request, so it belongs to staging or a short-lived debug session, never long-term on production. Remove the line when you are done. For a broader debug setup, WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY work together to surface PHP errors; see the white screen article for the order in which to review them.