wp-config.php: 12 Essential Settings for WordPress Developers

The default wp-config.php gets a site connected and little else. The constants that actually change how WordPress behaves in production, handoff, and debugging are the ones most teams end up adding later. If you want a faster way to assemble the right mix without hunting through docs, start with the wp-config.php Toggle Builder and use the list below to decide what belongs in your setup.

1. Start with the debugging trio, not a half-enabled debug flag

The common mistake is turning on WP_DEBUG alone and leaking warnings into HTML responses on a live site. The safer pattern is to enable debugging, write notices to a log, and keep them out of the browser so you can inspect issues without exposing paths, queries, or plugin internals to visitors.

These are three separate settings, and all three matter:

• WP_DEBUG
• WP_DEBUG_LOG
• WP_DEBUG_DISPLAY

Use this exact production-safe block on staging, and on live sites when you need active diagnosis without front-end leakage:

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

That gives you all 3 settings in one move:

1. WP_DEBUG turns on WordPress debugging mode.
2. WP_DEBUG_LOG writes errors and notices to wp-content/debug.log.
3. WP_DEBUG_DISPLAY stops those messages from rendering in the browser.

A typical use case is a client site throwing intermittent PHP notices only during checkout, form submission, or an AJAX request. You need the logs, but you do not want users seeing warnings mixed into JSON, redirects, or page markup. This block is the baseline.

One practical note: if you are debugging API responses or AJAX handlers, malformed output can also break status handling and payload parsing. When you need to verify whether the failure is an application error or a transport issue, an HTTP reference like the status code guide is useful alongside your debug log.

2. Remove the wp-admin file editor before it becomes a breach multiplier

DISALLOW_FILE_EDIT is one of the simplest and highest-value hardening changes you can make. It removes the built-in theme and plugin file editor from wp-admin, which means a compromised admin account cannot immediately be used to inject PHP through the dashboard.

Use this on every live site:

<?php
define( 'DISALLOW_FILE_EDIT', true );

This is setting 4 in the list, and it should be treated as non-negotiable for production. The practical risk is not theoretical: if someone gets access to an administrator account, the built-in editor gives them a direct path to persistent code execution by modifying functions.php or a plugin file. Turning this off removes that path entirely.

It also helps teams enforce a cleaner deployment model. Code changes should come from version control, CI, SFTP, or your deployment platform, not from an emergency edit in the dashboard that nobody remembers to backport later.

3. Need a stricter lockdown? Block all admin-side code changes

DISALLOW_FILE_MODS is broader than DISALLOW_FILE_EDIT. Instead of only removing the editor, it prevents plugin and theme installs, updates, and other file modifications from inside wp-admin. For handoff projects, managed hosting environments, and agency-maintained sites, that is often exactly what you want.

Use this when the dashboard should not be allowed to change code at all:

<?php
define( 'DISALLOW_FILE_MODS', true );

This is setting 5, and it is stricter than DISALLOW_FILE_EDIT in a way that matters operationally. If DISALLOW_FILE_EDIT says “don’t edit files in the browser,” DISALLOW_FILE_MODS says “don’t let the browser install or update code either.”

That difference is useful in scenarios like these:

• A client should manage content, not plugins.
• Updates are tested in staging and deployed through Git.
• Your host or agency owns patching and release timing.
• You want to stop well-meaning admins from installing random plugin ZIPs on production.

If you use this constant, make sure your update workflow is already in place. Otherwise you are trading dashboard convenience for operational discipline without a replacement process.

4. Lock down admin transport and make WordPress use the memory it actually needs

Two constants belong together because they solve two common “everything is technically working, but not reliably” problems: insecure admin transport and a memory ceiling that is too low for modern plugins.

First, the HTTPS side. If the site runs on HTTPS, wp-admin and the login flow should be forced onto HTTPS too:

<?php
define( 'FORCE_SSL_ADMIN', true );

This is setting 6, and on a properly configured HTTPS site it should be considered required, not optional. It helps ensure admin cookies, login requests, and dashboard traffic do not fall back to plain HTTP through a bad redirect rule, old bookmark, proxy quirk, or mixed environment configuration.

Second, the memory side. WordPress’s default memory baseline is often far below what current plugin stacks need. The default is 40MB, and many real-world installs need 256M just to avoid intermittent fatals in imports, builders, image processing, backups, and WooCommerce admin screens.

Use this for setting 7:

<?php
define( 'WP_MEMORY_LIMIT', '256M' );

The important distinction: WP_MEMORY_LIMIT does not override your server’s global PHP memory_limit if the host has set a lower ceiling. It tells WordPress what memory limit to request for itself. If your host’s PHP limit is 128M, setting WP_MEMORY_LIMIT to 256M will not magically grant 256M. You still need hosting or PHP-FPM configuration that allows it.

A common scenario looks like this:

• The host PHP limit is 512M.
• WordPress still runs with its lower default.
• A plugin-heavy admin page hits memory exhaustion.
• Raising WP_MEMORY_LIMIT to 256M fixes it without changing server-wide PHP behavior.

For security hardening beyond these constants, the functions.php Snippet Builder is a good companion when you want to add admin restrictions or cleanup snippets without manually piecing them together.

Here is the full security lockdown block from settings 4 through 6 exactly as you can paste it:

<?php
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
define( 'FORCE_SSL_ADMIN', true );

5. Stop feeding your database endless revisions and autosaves

Settings 8 and 9 are quiet but expensive when ignored. On content-heavy sites, unlimited revisions plus aggressive autosaves can turn the posts table into a graveyard of historical copies that slow backups, inflate exports, and make database maintenance more annoying than it needs to be.

Use these exact constants:

<?php
define( 'WP_POST_REVISIONS', 3 );
define( 'AUTOSAVE_INTERVAL', 120 );

Here is what each one does:

• WP_POST_REVISIONS limits how many revisions WordPress keeps per post. Setting it to 3 gives editors a safety net without storing dozens or hundreds of copies.
• AUTOSAVE_INTERVAL changes autosave frequency in seconds. Setting it to 120 means one autosave every two minutes instead of the default one-minute rhythm.

This matters most on sites with:

• long-form editorial workflows
• reusable block-heavy pages
• multiple editors touching the same content
• imported content that has gone through repeated revisions
• WooCommerce product catalogs with frequent updates

Imagine a newsroom site with 2,000 articles and several rounds of edits per article. If each post accumulates 20, 30, or 50 revisions, you are carrying a lot of rows that add little value after publication. Capping revisions to 3 usually preserves enough editorial rollback history while cutting long-term bloat dramatically.

If you want to inspect export payloads or plugin-generated JSON while cleaning up content pipelines around revision-heavy workflows, the JSON formatter is handy for validating and reading those blobs without leaving the browser.

6. Replace fake cron with a real scheduler

DISABLE_WP_CRON is setting 10, and it fixes one of WordPress’s most misunderstood reliability problems. WordPress’s built-in cron is not a real daemon. It only runs when someone visits the site, which means scheduled jobs can be delayed on low-traffic sites and over-triggered on busy ones.

Use this in wp-config.php:

<?php
define( 'DISABLE_WP_CRON', true );

Then add a real server cron job:

*/15 * * * * curl https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

That exact pairing is the fix:

<?php
// In wp-config.php:
define( 'DISABLE_WP_CRON', true );
// In your server crontab:
// */15 * * * * curl https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Why this matters in practice:

• On a low-traffic brochure site, scheduled publishes may not fire on time because nobody visited the site at the target minute.
• On a busy membership or ecommerce site, multiple requests can pile into cron spawning behavior and create unnecessary overhead.
• On staging, cron can unexpectedly run tasks you did not mean to trigger, especially if scheduled events were copied from production.

A real cron job gives you deterministic execution. Every 15 minutes is a reasonable baseline for many sites, though some workloads need 5-minute intervals and others are fine with hourly. The point is not the exact number; the point is moving scheduling responsibility to the server where it belongs.

7. Two dev-only switches that save hours: unminified assets and query logging

Settings 11 and 12 are for development and active investigation, not for normal production traffic. They are incredibly useful when you are tracing why a script handle is loading the wrong asset, why CSS changes are not behaving as expected, or which database call is turning a page into molasses.

First, SCRIPT_DEBUG tells WordPress to load development versions of core CSS and JavaScript files:

<?php
define( 'SCRIPT_DEBUG', true );

That makes debugging easier when you need readable sources instead of minified bundles. It is especially helpful when you are checking dependency order, script conflicts, block editor asset loading, or whether a plugin is relying on a core asset that changed behavior.

Second, SAVEQUERIES tells WordPress to store database query data in $wpdb->queries:

<?php
define( 'SAVEQUERIES', true );

Then use the required output snippet exactly as written:

<?php
global $wpdb;
if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES ) {
    echo '<pre>';
    print_r( $wpdb->queries );
    echo '</pre>';
}

That array includes the SQL query, execution time, and the call stack reference that triggered it. When a custom archive template suddenly performs 120 queries instead of 20, or an options lookup is firing repeatedly inside a loop, this is one of the fastest ways to see the damage.

A common workflow looks like this:

1. Enable SAVEQUERIES locally or on staging.
2. Load the slow page.
3. Print $wpdb->queries.
4. Sort or scan for repeated statements and long-running queries.
5. Move expensive calls out of loops, cache repeated lookups, or fix a plugin making uncached option or meta queries.

Do not leave either of these enabled on production unless you are actively troubleshooting and understand the cost. SCRIPT_DEBUG changes asset behavior, and SAVEQUERIES adds memory and performance overhead because WordPress stores every query for the request lifecycle.

For clarity, here are the final two settings together:

<?php
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );

And since this post is about the exact constants that matter, here is the complete 12-setting checklist in plain English:

1. WP_DEBUG
2. WP_DEBUG_LOG
3. WP_DEBUG_DISPLAY
4. DISALLOW_FILE_EDIT
5. DISALLOW_FILE_MODS
6. FORCE_SSL_ADMIN
7. WP_MEMORY_LIMIT
8. WP_POST_REVISIONS
9. AUTOSAVE_INTERVAL
10. DISABLE_WP_CRON
11. SCRIPT_DEBUG
12. SAVEQUERIES

Those are the wp-config.php settings most developers end up needing once a site leaves the default install state and enters the real world of deployments, client handoffs, plugin stacks, scheduled jobs, and performance debugging.

You now know which constants actually matter and why. Which of these are already in your default project boilerplate, and which ones are still getting added case by case? Open the wp-config.php Toggle Builder to generate the exact lines for your setup and stop rebuilding the same config decisions from scratch.