wp-config.php constants that actually matter

The constants in wp-config.php that actually matter are your database credentials, security keys, and a short list of behavior switches such as WP_DEBUG_LOG, DISABLE_WP_CRON, DISALLOW_FILE_EDIT, and FS_METHOD. This file is plain PHP, not a WordPress admin screen, so a single bad character or wrong value can white-screen the site or lock you out of the database.

Find the live file before you edit

WordPress loads the first wp-config.php it finds as it walks up the directory tree. If you edit public_html/wp-config.php while an older copy sits above it, PHP may still be reading the parent file. Confirm you are changing the path that the site actually uses, then restore from JetBackup if the live file is damaged.

Never leave a backup named wp-config.php.bak inside the web root. Scanners request that name on purpose and will pull your database password if the file is reachable.

php -r ‘echo token_get_all(file_get_contents(“wp-config.php”))[0][1] ?? “okn”;’

Run that command from the directory that holds the live file. If the first token is a BOM or stray whitespace before <?php, you will see headers-already-sent errors or a blank page. Save the file as UTF-8 without BOM in a real editor, not in a tool that inserts a byte-order mark for you.

Database constants and table prefix

DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST must match what cPanel shows under MySQL Databases. Wrong values produce “Error establishing a database connection,” not a theme problem. On this stack, DB_HOST is normally localhost (or the local socket) unless we told you otherwise. A hostname that does not resolve inside the CloudLinux jail will break the connection even when the password is correct.

After a restore, compare those four values to the current database name and user. A renamed database with an old wp-config is a common cause of a sudden connection error. The table prefix must match the tables that actually exist. Changing the prefix in the file without renaming the tables leaves you with an empty site on the old files.

Keys, debug, cron, and file edits

The AUTH and security key constants control cookie signing. Changing them logs everyone out, which is useful after a compromise. Set WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false when you need a log you can read without showing errors to visitors.

Set DISABLE_WP_CRON to true only when a real server crontab is already firing wp-cron.php. Leave it false if you have not set that job up. DISALLOW_FILE_EDIT set to true blocks the theme and plugin editors in wp-admin, which reduces damage if an admin account is abused.

On shared hosting here you own the account files, so FS_METHOD direct is the right value. That lets WP Toolkit and plugins write updates without asking for FTP credentials inside wp-admin.

Treat wp-config.php like secrets: keep one clean live copy, no public backups, and only the constants you intentionally set. That keeps database logins, keys, and those behavior switches under your control instead of under a scanner or a stray BOM.