Most wp-config.php files I inherit from clients look exactly like the default one WordPress ships, with maybe the database details filled in. wp-config.php is the file that holds your site’s core settings — database connection, security keys, and a set of optional switches most people never touch. That’s fine, right up until something breaks: there’s no debug log to check, a bloated database starts slowing down every save, or someone edits a plugin file live on production and takes the whole site down.

Here’s what I actually add or change on every install, and why each one matters — not just what it does.

Debug settings — visible only where I can see them

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

The mistake I see most often is turning on WP_DEBUG by itself. That enables debug mode, and by default also displays PHP notices and warnings directly on the page — in front of actual visitors, on a live site, leaking file paths and half-broken output into the HTML.

Setting WP_DEBUG_DISPLAY to false and WP_DEBUG_LOG to true gets you the same information, but privately. It gets written to a file at wp-content/debug.log instead, where no visitor ever sees it. I leave this combination on even in production, quietly, because a debug log with nothing in it costs nothing. Having one ready the moment something starts throwing warnings saves a lot of guessing later — it’s the same log worth checking if you ever hit the block editor’s “Updating failed” error and need to see what actually broke on save.

DISALLOW_FILE_EDIT — because plugin editor access is a live liability

define( 'DISALLOW_FILE_EDIT', true );

WordPress has a built-in Plugin and Theme file editor, tucked under the Appearance and Plugins menus, that lets any admin-level user edit PHP files directly in the browser. Changes take effect the instant they’re saved — no version control, no backup, and no real check beyond WordPress’s own basic guard against a fatal syntax error.

If an admin account is ever compromised, that editor becomes a one-click path to injecting arbitrary code into a live site. I disable it everywhere except my own local development setup, where I actually want the shortcut sometimes. It doesn’t stop file edits made via FTP or SSH — someone with direct server access can still change files — but it closes the easiest, most commonly abused door.

WP_MEMORY_LIMIT — for margin, not for the exception

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

These two constants control how much memory PHP is allowed to use while running your site. WP_MEMORY_LIMIT is the ceiling for regular front-end and admin pages. WP_MAX_MEMORY_LIMIT is a higher ceiling reserved for heavier admin-side tasks, like the media library or plugin updates.

The default is often too tight the moment you add a handful of plugins plus a page builder. You start seeing “allowed memory size exhausted” errors during things like bulk plugin updates or large image processing. I set these deliberately during setup rather than waiting for the error to show up, since raising a memory ceiling in the middle of a client’s crisis is a worse time to do it than at the start. One caveat worth knowing: your host’s actual PHP memory limit, set in their own server configuration, still caps this. WordPress can’t grant itself more memory than the server allows, no matter what you put here.

WP_POST_REVISIONS — bounded, not unlimited

define( 'WP_POST_REVISIONS', 10 );

By default, WordPress keeps every single revision of every post, forever. On a site with active editors autosaving every minute, that adds up to thousands of extra database rows within a few months — and every one of them still gets touched by queries that don’t always filter revisions out efficiently. I’ve seen the revisions table alone outweigh the actual content table on older sites, which is part of why an aging site’s admin area can start to feel sluggish over time — the same kind of slow-admin symptom I cover in my post on debugging a slow WordPress admin dashboard.

Setting a number like 10 keeps enough history to recover from a bad edit, without letting the table grow without limit. If a client specifically needs full revision history for compliance reasons, I’ll set it higher or leave it at the default — but that should be a deliberate decision, not an accident nobody made on purpose.

AUTOMATIC_UPDATER_DISABLED — think about this one before setting it

define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

This one isn’t a blanket “always disable” for me — it depends on who’s actually watching the site day to day. If I or the client are actively monitoring it and applying updates on a schedule, I’ll disable full automatic updates and keep WP_AUTO_UPDATE_CORE set to minor. That way security patches still land automatically, while bigger version jumps wait for a deliberate, tested update.

For sites nobody is actively maintaining, though, I actually leave automatic updates on. An unmaintained site with updates disabled is far more dangerous than one that occasionally has an update-related hiccup. Treat this constant as a tool, not a default — decide based on who’s really watching the site, not on habit.

FORCE_SSL_ADMIN — because the login form is the one place SSL isn’t optional

define( 'FORCE_SSL_ADMIN', true );

If your site has a valid SSL certificate — and at this point, almost every host provides one for free — this forces your entire admin area and login process over HTTPS, the encrypted version of your site’s connection. It does this even if someone lands on an old, unencrypted admin link.

Without it, login details or session cookies can end up sent in plain text if any part of the chain isn’t already forcing HTTPS — for example, an old bookmarked link to your login page. This one is nearly free to enable and closes a real gap, so I set it on every install that has SSL, which by now is effectively all of them.

The pattern behind all of these

None of these are exotic settings. They’re all cases where the WordPress default was chosen to be safe and workable for the widest possible range of sites — which means it’s rarely the ideal choice for a specific site you actually know something about. Setting them deliberately during initial setup takes about five minutes and avoids finding out about the gap the hard way, usually during an incident rather than before one. If you’re setting up a new install alongside a staging copy, it’s worth applying the same thinking there too — see my post on setting up a WordPress staging site on shared hosting for how the database side of that fits together.

Frequently Asked Questions About wp-config.php Settings

Do I need a developer to make these changes?

You’ll need at least FTP, SSH, or File Manager access to edit wp-config.php directly, since it isn’t editable from inside WordPress itself. The edits are just adding lines of text, so a developer can make all of these changes in a few minutes if you’d rather not do it yourself.

Will any of these settings break my site if I get them wrong?

A genuine typo in wp-config.php can take your whole site down, since PHP will refuse to run a file with a syntax error. Always keep a backup of the original file before editing, and add one constant at a time if you’re doing this yourself, so it’s easy to tell which change caused a problem if one shows up.

Is turning on WP_DEBUG safe on a live site?

Yes, as long as you pair it with WP_DEBUG_DISPLAY set to false. That combination logs errors privately to a file instead of showing them to visitors, so there’s no risk of leaking technical details on a live page.

How do I know if my host already restricts my memory limit?

Ask your host directly, or check your hosting control panel’s PHP settings — most show the current memory limit value there. If your host’s limit is lower than what you set in wp-config.php, the host’s number wins, so there’s no harm in setting a generous value here.

Why do revision limits matter if my site isn’t that busy?

Even a modest site accumulates revisions faster than people expect, especially if multiple people edit the same pages. It’s less about your current size and more about avoiding a slow, gradual buildup that nobody notices until the database starts to feel sluggish years later.

Should I just copy these settings exactly as shown?

The debug and security settings are safe defaults for almost any site. The memory limits, revision count, and automatic-update behavior are worth adjusting to your own site’s size and how actively it’s maintained, rather than copied blindly.