WP-CLI: The Commands That Replace an Afternoon of Clicking

Many managed WordPress hosts include WP-CLI already; type wp --info over SSH and see. If it is missing, the official install is a single PHP archive: download wp-cli.phar from the WP-CLI project, check it runs with php wp-cli.phar --info, make it executable and move it somewhere on your PATH as wp.

On shared hosting without root access you can still keep the phar in your home directory and add an alias to your shell profile, so wp points at php ~/wp-cli.phar. The host needs to allow SSH; if it offers no shell access at all, that is a strong reason to look at a better host rather than a reason to skip WP-CLI.

Run commands from the WordPress root directory, or pass --path to point at it. Running as the same user that owns the files avoids creating files the web server cannot later modify.

Moving a site to a new domain means changing every stored URL. A text find-and-replace on an SQL export breaks serialised PHP data, because serialised strings record their own length; change the length of a URL inside one and the whole value fails to unserialise, quietly wiping widget settings and theme options.

wp search-replace understands serialisation and fixes the lengths as it goes. Always start with a dry run, which reports how many replacements it would make in each table without changing anything: wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run.

Add --all-tables if plugins created tables without the WordPress prefix, and --skip-columns=guid to leave post GUIDs alone, as WordPress recommends. When the dry-run numbers look right, run it for real, then wp cache flush to clear any object cache still holding old values.

wp user list shows every user, and filters such as --role=editor narrow it. Combined with --field=ID, the output feeds straight into other commands, which is how bulk changes that would take an hour of clicking take seconds.

• Change a role for one user with wp user set-role, giving the username or ID and the new role.
• To demote every editor to author, list editors with --field=ID and pipe the IDs to wp user set-role one at a time. Review the list output before you pipe it anywhere.
• Reset a locked-out administrator's password with wp user update and a new user_pass value, or use wp user reset-password to email a reset link instead of typing a password into your shell history.
• Create an emergency administrator with wp user create and --role=administrator, and delete it as soon as the problem is fixed.
• Remove a departed team member with wp user delete and --reassign, so their posts move to another user instead of being deleted.

wp db export writes a full SQL backup to a file in one command, and wp db import restores one. Export before every risky change; it is the cheapest insurance available.

wp db size --tables shows which tables are large, which is usually the first clue when a database has bloated. Expired transients are a common culprit, and wp transient delete --expired removes them safely. wp db optimize runs the database's own optimisation on every table, which can reclaim space after a large cleanup.

For anything more targeted, wp db query runs SQL directly. That is powerful and unforgiving, so export first and test the query as a SELECT before running it as an UPDATE or DELETE.

• wp core verify-checksums compares WordPress core files against the official release and lists anything modified or added. On a clean site it reports success; on a compromised one it often points straight at the problem.
• wp plugin verify-checksums --all does the same for plugins from the WordPress.org directory, revealing edited or injected plugin files.
• wp plugin list --update=available shows outdated plugins, and wp plugin list --status=inactive shows ones that are installed but not used and should probably be removed.
• wp user list --role=administrator shows everyone with full control. Unknown administrator accounts are one of the clearest signs of a past compromise.

WordPress's built-in scheduler, WP-Cron, is invisible in the dashboard, which makes it hard to debug missed scheduled posts, failed backups or a plugin that schedules thousands of events. wp cron event list shows every scheduled event with its next run time and recurrence.

wp cron event run with an event name runs it immediately, and --due-now runs everything that is overdue. That is the fastest way to test whether a scheduled task works without waiting for a visitor to trigger WP-Cron. If you see the same hook scheduled hundreds of times, a plugin is registering events without checking whether they already exist.

• Take a database export before any command that changes data. It takes seconds and saves days.
• Use --dry-run wherever a command supports it, and read the numbers before running for real.
• Add --skip-plugins and --skip-themes when a broken plugin or theme stops WP-CLI loading. You can then deactivate the culprit with wp plugin deactivate.
• Double-check which site you are on before running anything destructive. A prompt that shows the server name or environment avoids running a production command on the wrong server.
• Keep commands you use often in a small script in the project repository, so the next migration uses the same tested steps.