The WordPress admin is a fine piece of software. What it does not give you is a record of what you did. Explaining the order you clicked things in means writing it out afterwards, and repeating it on staging means somebody reading that write-up and clicking again.
WP-CLI is the official command line interface for WordPress. Do the same job as a command and the command is the documentation, then the script, and eventually the check your pipeline runs. This series follows that move over eight parts.
Where commands beat clicks
Speed is not really the point. The difference shows up the second time you do the job.
Installing — one file to download
WP-CLI ships as a single .phar. Download it, make it executable, put it on your path.
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wpDo not skip the --info step. It reports which PHP binary is running the tool, its version and which ini file it loaded. A surprising share of later trouble starts from the fact that the PHP your web server uses and the PHP your shell uses are not the same one.
What changes between the server and your machine
Same tool, different things to watch. Settle these three at the start and the rest stays quiet.
The user matters most. Running as root produces a warning. You can push past it with --allow-root, but every cache file, upload and log created in that run ends up owned by root, and the web server can no longer write to them. On a server, run as the web user: sudo -u www-data wp ….
The PHP binary is the local-machine problem. System PHP and the PHP bundled with your local development tool are frequently different builds, so extensions go missing or the version drops only in the shell. The fix is dull and effective — keep a short wrapper script that pins the PHP path in the repository, and have everyone use that.
Location is handled by --path=. If your repository root and the WordPress document root differ — a wordpress/ folder inside the repo, say — nothing works from anywhere without it.
Your first five commands
Once installed, run these in order. Together they tell you the state of the site in one screen.
wp --info
wp core version --extra
wp option get home
wp plugin list --status=active --field=name
wp db checkThe fourth is the quietly useful one. Diff that list against the plugin list in your documentation and you immediately see what somebody added and never wrote down. That single line later becomes the first check in your pipeline (part eight).
Two errors you will meet on day one
“This does not seem to be a WordPress installation” means there is no WordPress in the current directory. Pass --path or change into the document root.
A database connection failure while the site itself is fine in a browser usually means the database host resolves differently in the shell. Check whether the socket path or hosts alias is only valid in the web server context.
When a single broken plugin stops the command from booting at all, --skip-plugins --skip-themes gets you a minimal boot to work from. That flag is the first step in finding the culprit.
Related articles are collected in the development workflow archive, and the free diagnostic plugins we publish come with their command line usage on the free tools page.
Next part
With the tool in place, it is time to touch real data. The next part covers posts and terms from the command line, and it has one governing rule: list before you change.