WP-CLI Workflows Every WordPress Developer Should Know

Every task you do through wp-admin with clicks and page loads, WP-CLI does in a line, and a line can be scripted, scheduled and put in a deployment pipeline. It ships with most decent hosting and takes minutes to install anywhere else. These are the workflows we lean on constantly, roughly in order of how often they save us. None of it requires deep Unix knowledge, just a willingness to type where you used to click.

The everyday layer

The basics repay learning properly: wp plugin list with its status and update columns is a faster health check than any dashboard screen, wp user create gets you a temporary admin on a client site in seconds, and wp cache flush plus wp transient delete --expired resolve a surprising share of mystery behaviour. Almost every command takes --format=json or --format=ids, which is what makes composition possible. And wp db export before anything risky is the habit that pays for all the others, because it turns every experiment into something reversible.

Search-replace without fear

Changing a site URL by editing the database directly breaks serialised data; WP-CLI's search-replace understands serialisation and handles it correctly. The habit that keeps it safe is simple: dry-run first, read the table-by-table report, then run it for real.

# Report what would change, without changing it
wp search-replace 'https://old.example' 'https://staging.example' \
  --all-tables --dry-run

# Then do it, exporting a safety copy first
wp db export /tmp/pre-replace.sql
wp search-replace 'https://old.example' 'https://staging.example' \
  --all-tables

Bulk operations and small scripts

The ids format turns WP-CLI into a proper Unix citizen. Piping wp post list --post_type=attachment --format=ids into xargs with wp post delete clears thousands of orphaned attachments in one line; the same pattern updates meta across every page, regenerates thumbnails for a subset of media, or deactivates every plugin matching a pattern while you debug. For anything beyond a one-liner, wp eval-file runs a PHP script with WordPress fully loaded, which is our preferred home for one-off data migrations: version-controlled, reviewable and repeatable on staging before production. One caution: a pipeline into xargs has no undo, so run the listing half on its own first and read what comes back before you add the destructive half.

Diagnosis: profile, doctor, shell

The profile and doctor command packages are worth installing everywhere. wp profile stage shows where bootstrap time goes, and wp profile hook narrows it to the hook and callback wasting the time, which turns a vague slow-site complaint into a named plugin in about two minutes. wp shell gives you a REPL inside the running site, ideal for poking at a function's actual return value rather than guessing from documentation.

Deployment pipelines and scaffolding

The same commands compose into deployment steps. After new code lands on a server, a short script can flush the object cache, run any pending database migrations, warm the page cache for key URLs and verify the site responds before traffic moves over; every step is a command with an exit code, so the pipeline stops on failure instead of shipping a broken release. Scaffolding belongs in the same toolbox: wp scaffold generates plugin boilerplate, post type registrations and test setups, which keeps new work consistent across a team without anyone cloning an old project as a starting point.

Aliases: the same commands, any environment

A wp-cli.yml with @staging and @production aliases pointing at SSH targets means every workflow above runs against remote environments from your local terminal, and @all runs a command across every environment at once, which is how a plugin update check across a whole client portfolio becomes one line. Combined with a scheduled script, the same mechanism powers routine maintenance reports that arrive before anyone has opened a dashboard. Give the production alias some friction, a distinct prompt colour or a confirmation wrapper, because the reach that makes aliases useful is exactly what makes them dangerous.

None of this is exotic; it is the accumulation of small speed-ups that compounds. Put WP-CLI at the centre of how you operate WordPress and the admin becomes something you visit, not somewhere you live.