Managing wp-config.php with the WP-CLI config command

The WP-CLI config command edits the values and constants in your wp-config.php file, which is a safer way to change WordPress settings than hand-editing the file. It runs before WordPress loads, so it cannot be blocked by a syntax error or a white screen that stops the rest of WP-CLI from booting.

The config subcommands

The wp config family manipulates the file made of constants, for example WP_DEBUG and DB_HOST, and variables. The useful subcommands are:

• wp config list shows the current constants and variables defined in the file.
• wp config get <name> returns the value of one constant or variable.
• wp config set <name> <value> sets a value, adding it if it is not there by default.
• wp config delete <name> removes a value.
• wp config path prints the path to the config file, handy when WP roots differ from the current directory.

The default target is the wp-config.php at the root of the WordPress install. Use the --type flag to target only constants or only variables, since both live in the same file.

Setting values safely

The override that matters most is --raw. Without it, WP-CLI wraps the value in quotes, so passing the string true becomes 'true'. Many constants such as WP_DEBUG need the literal boolean, so they are set with --raw:

wp config set WP_DEBUG true --raw

Other flags give you control over where a value is written. The --anchor and --placement flags locate new values relative to a marker string, defaulting to the "stop editing" line. The --config-file flag points at a different file, which helps when you manage an install whose config is outside the web root.

A typical routine is to read first, change, then confirm:

wp config get DB_HOST
wp config set WP_MEMORY_LIMIT 256M --raw
wp config list

Common examples

• Enable debug logging when a site is misbehaving:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw

• Switch each of the database-related constants during an environment move, instead of editing credentials by hand.

The value of the command is repeatability: you can script config changes, keep them out of manual edits, and avoid the syntax error that leaves a site white. Where a bad manual edit to wp-config.php produces a fatal error before WordPress loads, WP-CLI's config command still works because it runs before the load. That makes it a useful first step in a recovery flow, alongside the WordPress troubleshooting order and the white screen of death walkthrough.