Installing WordPress with WP-CLI

Why scaffold with WP-CLI

A fresh WordPress install is normally a browser form: download, create a wp-config, run wp-admin/install.php and answer the fields. WP-CLI (wp) does the same work from a terminal, which matters when you are provisioning many installs, scripting a staging or VPS setup, or automating a pipeline where a browser never opens. It also leaves a history you can repeat, which makes the next install take seconds instead of minutes.

WP-CLI needs PHP to exist on the server (the php binary) and a writable document root. Check both before starting; the hosting panel versus WP-CLI comparison explains where WP-CLI fits among the alternatives.

Step 1: download WordPress core

From the directory that will become the document root (empty, or ready to receive the release):

wp core download

That downloads the latest stable WordPress into the current directory. Useful flags:

• --version=6.6.2 downloads a specific release (pin it for reproducible staging builds).
• --locale=en_GB selects a locale; other values are supported per install.
• --force overwrites an existing copy, useful when you re-scaffold.

Step 2: create wp-config

WP-CLI can generate wp-config.php from the database details, with a random set of salts:

wp config create --dbname=mydb --dbuser=myuser --dbpass=secret \
  --dbhost=localhost --path=. --skip-check

The --skip-check keeps WP-CLI from trying to connect to the database while creating the file; separate from that, the command generates a standard wp-config.php with unique authentication keys and salts that it never prints to the terminal.

Step 3: install core and the database

With configuration in place, install core against a database that already exists:

wp core install --url="https://example.com" \
  --title="Example site" \
  --admin_user=admin --admin_password="h4rd2guess" --admin_email="[email protected]"

The order matters less than the result: the install writes the options (home and siteurl), creates the default tables, and sets the admin user with a hashed password. WP-CLI prints the resulting site URL on success. Create the database first (wp db create on a host where WP-CLI can create databases, or via your panel), because wp core install expects it to exist.

Step 4: finish the site config

The scaffold leaves two things to attend to:

wp rewrite flush --hard
wp option update timezone_string Europe/London

The rewrite flush is what lets pretty permalinks work (needed before the first non-root page works at /topics/... URLs). The timezone is cosmetic but defaults to UTC in a fresh install. Set the site language, and a default admin plugin set only if your process does it elsewhere.

Verify what the scaffold produced

• wp core version prints the release.
• wp option get siteurl and wp option get home confirm the domain.
• wp user list shows the admin user.
• Visit the domain once in a browser to confirm first-run works, and run the site health check quickly if the panel has one.

Troubleshooting the scaffold

• wp command not found: WP-CLI is an optional download, not part of WordPress; install the CLI first per your host's docs.
• Permission error writing wp-config: WP-CLI can't write where PHP can't write; fix ownership of the document root.
• The parser fails on --dbpass special characters: wrap the value in single quotes, and if it contains quotes, generate a password without them.
• Misspelt slug in --url: fix wp option update siteurl https://example.com and wp option update home https://example.com after install.

Prevention

Treat the scaffold as a repeatable script rather than a one-off: keep the wp core install line in a notes file or a small shell script, so the next environment is installed the same way with no guesswork. WP-CLI's own scripting power is covered in the media WP-CLI guide, and the release pipeline you build around it connects to the staging to live flow.