Why Is wp-config.php So Critical?
wp-config.php is the most fundamental configuration file in a WordPress installation. It holds the settings a site needs to run at all, from the database connection details to the table prefix. But the file's real power lies in the optional PHP constants you can add to it: with these constants you can change debugging behaviour, whether the file editors in the admin panel are enabled, whether SSL is enforced, the memory limit and many other core behaviours. The catch is that most of these constants are not defined by default in a WordPress installation, and if you do not know where and how to add them they have no effect at all.
Adding Constants in the Right Place: The Ordering Rule
In PHP, once a constant has been defined with define() it cannot be redefined — a second define() call is silently ignored and does not even raise an error. The WordPress core also defines its own default values for some of these constants further down, as the core files load. That is why the constants you add must come before the /* That's all, stop editing! Happy publishing. */ line. If a constant is added after that line — that is, once the core's own default definition has already run — your define() line sits in the file but does nothing; you see no error message and no warning, the behaviour you expect simply never happens.
The 8 Most Widely Used Constants
| Constant | What it does | When to use it |
|---|---|---|
| WP_DEBUG | Enables debug mode, making PHP errors/warnings/notices visible. | In a development environment and when diagnosing problems. |
| WP_DEBUG_LOG + WP_DEBUG_DISPLAY | Writes errors to the <code>wp-content/debug.log</code> file instead of showing them on screen. | The recommended form of debugging on live (production) sites. |
| DISALLOW_FILE_EDIT | Completely disables the Theme Editor and Plugin Editor screens inside wp-admin. | From the start as a standard hardening step, or as a first response step after a security incident. |
| AUTOMATIC_UPDATER_DISABLED | Disables automatic core, plugin and theme updates. | On installations where updates are handled through a manual/controlled process. |
| FORCE_SSL_ADMIN | Requires an SSL (HTTPS) connection for wp-admin and the login screen. | On every site with an SSL certificate installed, to encrypt the admin session. |
| WP_POST_REVISIONS | Limits how many revisions are kept for a post (unlimited by default). | To keep database size under control. |
| WP_MEMORY_LIMIT | Increases the memory limit PHP allocates to WordPress. | On sites that get the 'Allowed memory size exhausted' error or use heavy plugins/themes. |
| EMPTY_TRASH_DAYS | Sets how long (in days) items stay in the trash before being deleted automatically. | To set trash behaviour to something other than the default 30 days. |
Short Notes on the Other Constants
Some of the constants in the table are talked about less but are useful in day-to-day administration. FORCE_SSL_ADMIN automatically redirects the session to an encrypted connection if someone tries to reach the admin panel over http:// by mistake even though your certificate is installed; it stops your login credentials travelling across the network in plain text. WP_POST_REVISIONS pins the revision history, unlimited by default, to a specific number — on a frequently edited content site this prevents the database tables from bloating needlessly over time. WP_MEMORY_LIMIT, meanwhile, sets the amount of memory WordPress alone can use, separately from your server's general PHP memory limit; if your hosting provider's php.ini setting is already sufficient this constant has no practical effect, but it is one of the first things to reach for when you meet a low default limit on shared hosting. AUTOMATIC_UPDATER_DISABLED should be used carefully: turning automatic updates off puts updates under your control, but it also puts the responsibility for tracking them by hand on you.
Debugging Correctly in Production: WP_DEBUG_LOG and WP_DEBUG_DISPLAY
When WP_DEBUG is turned on by itself, it prints PHP errors, warnings and notices directly onto the page, where visitors can see them too. That is useful for finding problems in a development environment, but if it is left on a live site it carries a risk of information disclosure: error output reveals server file paths, the plugin versions in use and the directory structure to attackers — a common and well-known class of vulnerability. The right approach is to use the WP_DEBUG_LOG and WP_DEBUG_DISPLAY constants together: errors are not shown on screen and are written to the wp-content/debug.log file instead. You can then diagnose the problem by examining the log file, while visitors see no error output at all. This combination is the recommended form of debugging on production sites.
DISALLOW_FILE_EDIT: Both a Precaution and a Response Step
The built-in Theme Editor and Plugin Editor screens in the wp-admin panel are one of the most common routes by which an attacker who has gained access to the admin panel adds malicious PHP code straight into a theme or plugin file. That is why the DISALLOW_FILE_EDIT constant comes up in two different scenarios: as one of the well-known first response steps applied after a site has been compromised, and as a standard hardening step applied from the start without waiting for trouble. The second use is the wiser one — you take the precaution before anything goes wrong, and even an admin session that falls into an attacker's hands cannot add code this way.
Example: Using Several Constants Together
The point to watch is that all of these lines sit before the comment line mentioned above, in the still-editable part of the file. Their order among themselves does not matter, but their position absolutely does.
Common Mistakes
- Adding constants after the
/* That's all, stop editing! */line — they sit in the file but have no effect whatsoever. - Leaving
WP_DEBUG_DISPLAYenabled on a live site and showing error output to visitors. - Thinking these constants replace real security measures (a strong password, up-to-date software, a firewall, regular backups) — they are supporting, complementary settings, not a security strategy on their own.
- Trying to define the same constant twice in the file; PHP does not treat that as an error, but the later
define()call is silently ignored.
Generating these constants with a tool that guarantees the right syntax and position, rather than typing them by hand, both saves time — especially for developers managing several sites — and eliminates the 'why isn't this working' questions that come from getting the order wrong.