wp-config.php Explained: The Settings Worth Knowing

Every WordPress site has a file called wp-config.php in its root folder. It tells WordPress how to reach the database and carries a set of switches that change how the whole site behaves. Most owners never open it, but knowing the handful of settings that matter can save hours of troubleshooting and tighten security. Always back up the file before editing, and a single misplaced character can take the site offline.

What the file contains

When you install WordPress, the setup creates this file from a template. It contains database connection details, security keys, the table prefix and a debug setting. It ends with a comment telling you to stop editing and a few lines that load the rest of WordPress. Add your own settings above that comment.

Because the file holds database credentials, treat it as sensitive. It should not be readable by other accounts on the server or exposed in a public backup folder. Never paste its contents into a public forum without removing the passwords.

Database settings and security keys

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'a-long-unique-password' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );

These lines must match a database and user that exist on the server. After a migration, wrong values here are the most common cause of the database connection error. The table prefix, set by the $table_prefix variable, lets several sites share one database. Changing it on an existing site means renaming tables and updating some rows, so do not alter it casually.

Security keys and salts

Eight constants (such as AUTH_KEY and SECURE_AUTH_SALT) add randomness to the cookies WordPress uses for logins. WordPress provides a generator at its official API for fresh values. Replacing them logs everyone out, which is a handy step after a security incident or when a former staff member should lose access.

Debugging settings

These constants help you see what is going wrong:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG turns on error reporting. WP_DEBUG_LOG writes messages to wp-content/debug.log. Setting WP_DEBUG_DISPLAY to false keeps errors off the screen, so visitors do not see them. On a live site, turn debugging back off when you are done, and delete the log if it contains sensitive paths.

Settings for performance, security, updates and URLs

Memory limit

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

This asks WordPress to use more PHP memory, up to what the server allows. If your host caps memory lower, this setting cannot exceed the cap. Heavy plugins, builders and shops often need more than the default.

Post revisions

define( 'WP_POST_REVISIONS', 5 );

WordPress saves every revision of a post by default. Limiting them keeps the database smaller. Use false to disable revisions, although having a few is useful if an edit goes wrong.

Trash retention

define( 'EMPTY_TRASH_DAYS', 14 );

Controls how many days deleted items stay in the trash before permanent removal.

Cron

define( 'DISABLE_WP_CRON', true );

This disables the visitor-triggered scheduler, and is only safe if you set up a real server cron job to call WordPress at regular intervals. Our article on WordPress cron explains the trade-offs.

Security-related settings

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

DISALLOW_FILE_EDIT removes the theme and plugin editors from the dashboard, which takes away a convenient tool from an attacker who gains admin access. FORCE_SSL_ADMIN forces the login and admin area over HTTPS. There is also DISALLOW_FILE_MODS, which blocks plugin and theme installs and updates from the dashboard; use it only if you manage updates another way, as it also stops automatic updates.

Update behaviour

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Valid values include true for all core updates, false to disable them, and minor for security and maintenance releases only. Choose according to how closely you monitor the site.

Site URL settings

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Defining these overrides the values in the database and removes the ability to change them from Settings. It is useful to regain access when a wrong URL has locked you out, or on staging copies. Remove them later if you prefer to manage the URLs in the dashboard.

Safe editing habits

1. Download a copy of the file before you change it.
2. Use a plain text editor, not a word processor that adds smart quotes.
3. Keep every line ending with a semicolon, and keep quotes straight.
4. Add custom lines above the comment that says to stop editing.
5. Reload the site and the admin straight away to check nothing broke.

If a mistake produces a blank page, restore your copy through the file manager or SFTP.

Moving the file and protecting it

On some setups, WordPress can load wp-config.php from one folder above the web root, which keeps it out of reach of the web server entirely. Whether this suits you depends on your hosting layout. Whatever you do, keep a recent copy of the file in your backups, since it holds the database details you need for a restore. If you copy a site to staging, create a separate database and user for the copy and change the values in its file, so test activity never touches live data.

Where this fits at Zebra Hosting

With Plesk on every plan, you can reach your files, PHP settings and databases from one place, which makes wp-config.php changes straightforward. Our WordPress hosting is set up automatically within minutes of payment, and the knowledgebase has guides for common Plesk tasks.