wp-config.php Reference

Every request enters through wp-load.php (directly, or through index.php, wp-admin/admin.php, wp-cron.php and the other entry points). The order of events is what makes a constant work or not:

Three consequences follow. A constant must be defined above the require_once line, which is why the sample file marks the place with "Add any custom values between this line and the "stop editing" line". A PHP constant cannot be redefined, so the first definition wins and a plugin cannot override a value set in wp-config.php (redefining one raises a "Constant already defined" warning and keeps the old value). And nothing in wp-config.php can call WordPress functions such as add_filter(), because they are not loaded yet; filters that tune updates, cron or HTTP belong in a must-use plugin in wp-content/mu-plugins/.

The database settings, keys and prefix that every file contains are shown, with their explanation, in Installation; the full environment-driven file used by Lumen Press is at the end of this page.

Save the file as UTF-8 without a byte order mark, with nothing before <?php. It needs no closing ?>; any byte after one is sent to the browser and causes "headers already sent" errors.

Source: Advanced Administration Handbook: wp-config.php

WP_ALLOW_REPAIR repairs table structures; it does not reset passwords. An older book recommends it for regaining access to a locked-out account, which it cannot do; use wp user update lp_admin --user_pass=<new-password> (or the "Lost your password?" e-mail) instead, as described in Security Hardening.

The eight constants AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT sign the login cookies and nonces. They are generated once per site by the WordPress.org secret-key service or wp config shuffle-salts; their generation and what happens when one is missing are explained in Installation. Changing them logs every user out, which is the standard response to a suspected compromise. They are not encryption keys: a database dump does not depend on them, and nothing in wp-config.php is "encrypted" by WordPress. An older book suggests encrypting the values in wp-config.php; PHP must read them in clear text on every request, so the real protections are file permissions, a location outside the web root and, best, keeping the secrets out of the file altogether (environment variables or a secret manager).

Source: Advanced Administration Handbook: wp-config.php

Pinning WP_HOME and WP_SITEURL per environment is the usual way to stop a staging copy from redirecting to production after a database import; the full move procedure, with wp search-replace, is in Importing, Exporting and Migrating. The cookie flags themselves (HttpOnly, Secure) are covered in the Cookies article of the Advanced Administration Handbook.

Source: Advanced Administration Handbook: wp-config.php

There is no constant for the themes directory: a plugin can add one with register_theme_directory(). A layout that keeps core in its own directory (/wp) and wp-content beside it, as Composer-based setups do, uses the URL and content constants together: WP_SITEURL points to /wp, WP_HOME to the root, and WP_CONTENT_DIR/WP_CONTENT_URL to the content directory beside it, as described in Giving WordPress Its Own Directory.

WP_ENVIRONMENT_TYPE (WordPress 5.5) tells core, plugins and hosts which kind of environment runs the code. The accepted values are local (added in 5.5.1), development, staging and production. wp_get_environment_type() resolves it in this order:

Core itself uses it in a few places: development turns WP_DEBUG on when WP_DEBUG is not defined, and local relaxes the HTTPS requirement of application passwords. Plugins use it to disable e-mails, payment gateways or search indexing outside production. The list of types cannot be extended; a WP_ENVIRONMENT_TYPES constant was removed in 5.5.1 and now only triggers a deprecation notice. Each line below was run against a wp-config.php that does not define WP_DEBUG:

Source: Code Reference: wp_get_environment_type()

WP_DEVELOPMENT_MODE (WordPress 6.3) is a separate switch for people working on code: core, plugin, theme, all, or '' (default). It does not change error output; it changes caching that gets in the way of development, for example theme stops global styles and theme.json data from being cached. wp_is_development_mode( 'theme' ) checks it, and all matches every type. A non-empty development mode also turns WP_DEBUG on when WP_DEBUG is not defined. Never set it in production.

Source: Make WordPress Core: Configuring development mode in 6.3

Source: Advanced Administration Handbook: Debugging in WordPress

wp-content/debug.log is inside the web root, so on most servers anyone can download it, together with paths, query fragments and sometimes personal data. Site Health reports both a displayed and a publicly reachable log. In production, either keep WP_DEBUG off or log to a path outside the web root and never display:

Source: Advanced Administration Handbook: Debugging in WordPress

Tools, Site Health and troubleshooting procedures are on Debugging, Site Health and Troubleshooting.

WP_MEMORY_LIMIT is the PHP memory limit WordPress asks for on every request, and WP_MAX_MEMORY_LIMIT the one it asks for in heavier admin tasks (image processing, updates, imports). Core defaults are 40M on a single site, 64M on Multisite, and 256M for the maximum. Both work by calling ini_set( 'memory_limit', ... ), with three rules that explain most "the constant does nothing" reports:

Measured in a web request on the wordpress:7.1.3-php8.4-apache image, whose php.ini sets 128M, first with no constants and then with WP_MEMORY_LIMIT at 256M and WP_MAX_MEMORY_LIMIT at 512M, using a throwaway probe script in the web root (delete such a file right after use):

Source: Advanced Administration Handbook: wp-config.php

On the same site converted to Multisite, WP_MEMORY_LIMIT reported 64M. An older book gives different Multisite memory defaults; the values above come from default-constants.php in 7.1.

Source: Plugin Handbook: Hooking WP-Cron Into the System Task Scheduler

Setting DISABLE_WP_CRON without adding the system job silently stops scheduled posts, update checks and the Lumen Press stock synchronisation. The cron setup is on WP-Cron and Scheduled Tasks.

FORCE_SSL_ADMIN set to true redirects wp-login.php and every admin page to HTTPS, so passwords and the authentication cookies never travel in clear text. Since the site URL decides its default, a site configured with https:// URLs already has it; defining it explicitly protects against a database import that brings an http:// URL.

FORCE_SSL_LOGIN was deprecated in WordPress 4.0, when logins and the admin were unified under FORCE_SSL_ADMIN. 7.1 still honours it (a true value calls force_ssl_admin( true )), but it should be replaced. On an http:// site with neither constant defined, then with only FORCE_SSL_LOGIN:

Source: Advanced Administration Handbook: HTTPS

Behind a load balancer or reverse proxy that terminates TLS, PHP sees plain HTTP and WordPress produces redirect loops or mixed content. Tell it about the original scheme, trusting the header only because the proxy always sets it:

Source: Advanced Administration Handbook: HTTPS

The official Docker image ships a similar block in its wp-config.php. On a server reachable without the proxy, anyone can send the header, so restrict direct access first.

Source: wordpress-develop: speculative-loading.php (7.1 branch)

A persistent object cache (Redis, Memcached, APCu) is a separate wp-content/object-cache.php drop-in that does not need WP_CACHE; its connection settings are constants defined by the drop-in’s plugin, not by core. Page caching, object caching and OPcache are on Performance and Caching.

Source: Advanced Administration Handbook: wp-config.php

Checked with five updates of one post for each revision setting, and with a trashed draft under EMPTY_TRASH_DAYS 0:

Source: Code Reference: wp_revisions_to_keep()

WP_POST_REVISIONS only limits revisions created from now on; existing extra revisions stay until the post is saved again. With EMPTY_TRASH_DAYS at 0, wp_trash_post() deletes the post outright (the post no longer exists), while with the default it moves the post to the trash status and records the time in _wp_trash_meta_time (also checked). An accidental click is unrecoverable without a backup, so Lumen Press keeps a short trash (14 days) rather than none.

WP_HTTP_BLOCK_EXTERNAL set to true makes the HTTP API (wp_remote_get() and friends) refuse every request except to the site itself and localhost. WP_ACCESSIBLE_HOSTS lists the exceptions, comma-separated, with * wildcards. Blocking api.wordpress.org also blocks update checks, plugin installs and translation downloads, so list it unless updates are deployed another way. For the Lumen Press stock synchronisation with its distributor:

Source: Advanced Administration Handbook: wp-config.php

Source: Common APIs Handbook: HTTP API

The block applies only to code that uses the HTTP API; a plugin calling cURL directly ignores it, so it is a policy, not a firewall. A forward proxy is configured with WP_PROXY_HOST and WP_PROXY_PORT (both required), WP_PROXY_USERNAME/WP_PROXY_PASSWORD, and WP_PROXY_BYPASS_HOSTS (comma-separated, wildcards allowed).

A network is enabled in two steps: WP_ALLOW_MULTISITE adds Tools > Network Setup, and the setup screen (or wp core multisite-convert) creates the network tables and prints the remaining constants. Converting the Lumen Press test site produced:

Source: WP-CLI Commands: wp core multisite-convert

Source: Advanced Administration Handbook: Create a Network

The web server rules and the tables a network adds are on Multisite Networks.

Several constants found in older books or old tutorials have no effect in WordPress 7.1. Defining them raises no error, which is why they survive in copied configurations. The dump at the top of this page shows WP_ADMIN_EMAIL and WP_USE_EXT_MYSQL as not defined, and a search of the 7.1.3 source finds no reference to WP_ADMIN_EMAIL at all.

Source: wordpress-develop: Database: Remove support for the mysql extension

A wp-config.php with literal passwords and keys cannot be committed to version control, and must be edited per server. Reading the values from environment variables makes the file identical in every environment and keeps the secrets in the platform that already manages them (Docker or Kubernetes secrets, the host’s control panel, a secret manager). Core helps in three places: WP_ENVIRONMENT_TYPE and, since 7.1, the two speculative loading defaults are read from the environment directly; everything else goes through getenv() in wp-config.php.

The Lumen Press configuration below reads every per-environment value and every secret from the environment. A NAME_FILE variable pointing to a file takes precedence, which is how Docker and Kubernetes secrets are mounted. A missing secret stops the request with a 500 and a log line, rather than letting WordPress fall back to empty credentials or database-stored salts:

Source: Advanced Administration Handbook: wp-config.php

Points about this file:

With the variables in an env file, the effective values were checked with WP-CLI, then with a different environment type and debug switch, and finally with the database password missing:

Source: PHP Manual: getenv

WordPress also finds wp-config.php one directory above its own directory, as long as that directory is not another WordPress install (it must not contain wp-settings.php). With the document root at /srv/lumenpress/public and WordPress installed there, /srv/lumenpress/wp-config.php is outside what the web server serves. Nothing else changes: ABSPATH keeps its default, contrary to an older book that says it must be edited after the move. Moving the file on the official image from /var/www/html/ to /var/www/ left the site working unchanged.

Source: Advanced Administration Handbook: Hardening WordPress

The Hardening page notes that the security benefit of the move is debated: a correctly configured PHP server never serves the file’s source, and the real exposure is a PHP handler failure or a backup copy (wp-config.php.bak, wp-config.php~) left in the web root, which the server will serve as text. Whatever the location, restrict the file to the owner and the web server group (chmod 440 or 400), block direct requests to it in the web server (see Web Servers: Apache and nginx), and never leave edited copies behind. With WordPress in a subdirectory of the document root (public/wp/), the "one level up" location is still inside the web root, so the two layouts do not combine; there, keep the secrets in environment variables instead.

The broader checklist (MFA, application passwords, XML-RPC, the database user) is on Security Hardening.