WP-CLI tricks I use every week

WP-Admin is for clients. WP-CLI is for me.

That is not a slogan, it is just how the work shakes out. Anything I am going to do twice, anything that touches the database, anything I would rather not click my way through at 11pm on a Friday when a client has paged me about a broken checkout, I do from the terminal. WP-CLI has been around forever and most WordPress devs know it exists, but I am still surprised how many people open the admin to do things that are one line in a shell.

Here are the eight commands I genuinely reach for almost every week, with what each one saves me. None of these are clever. They are just the boring tools that keep me out of trouble.

1. wp search-replace, the one that pays for the whole CLI

Migrating a site from staging.example.com to example.com and doing it with a SQL find-and-replace is how you end up with corrupted serialized arrays in your options table. WP-CLI handles serialization properly, which means widget configs, theme mods, and plugin options survive the move.

wp search-replace 'https://staging.example.com' 'https://example.com' \
  --all-tables --skip-columns=guid --dry-run

I always run with --dry-run first so I can see the count of replacements before committing. The --skip-columns=guid bit is important, GUIDs are identifiers, not URLs, and rewriting them breaks feed readers.

2. wp db export piped through gzip, the cheap insurance

Before any risky change (plugin update on a live site, theme switch, manual options edit) I take a one-line backup. The pipe to gzip keeps the file small enough to scp around without thinking about it.

wp db export - | gzip > backup-$(date +%Y%m%d-%H%M%S).sql.gz

The dash tells WP-CLI to write to stdout, which is what lets the pipe work. Thirty seconds of effort, infinite peace of mind. I have rolled back from one of these more times than I want to admit.

3. wp media regenerate after a theme switch

New theme means new image sizes, and the old uploads still only have thumbnails in the dimensions the previous theme registered. So every featured image looks soft or stretched until you regenerate. The CLI does it for the whole library without you babysitting the admin progress bar.

wp media regenerate --yes

On a big media library this takes a while, so I usually run it inside tmux or nohup and let it finish overnight. The --yes flag skips the confirmation prompt that otherwise stops it on the first item.

4. wp post list piped to xargs for bulk operations

This is the one I show people when they ask why CLI matters. Want to trash every draft product older than a year? Want to set a meta field on every post in a category? Compose two commands and let xargs do the loop.

wp post list --post_type=product --post_status=draft --format=ids \
  | xargs -d ' ' -I {} wp post delete {} --force

The --format=ids output is the magic ingredient, it gives you a clean space-separated list that xargs can chew through. Combine this with wp post meta update, wp term remove, or anything else and you have a tiny ad-hoc batch tool.

5. wp cache flush, used more than you would think

Object cache lying to you? Page cache showing the old menu? Did you just edit something in the database directly and the front end disagrees with reality? Flush.

wp cache flush

I run this so often I have a shell alias for it. It clears the persistent object cache (Redis, Memcached, whatever is wired up) and forces the next request to rebuild from the database. Half the time when a client says "it is not updating", this is the fix.

6. wp option update --autoload=no for the bloat problem

When a site gets mysteriously slow and the database is full of giant transients or plugin junk that loads on every single request, autoload is usually the culprit. Find the heavy options and switch them to lazy loading.

wp option update _transient_huge_thing 'value' --autoload=no

The more useful pattern is finding what to fix first. I list the top autoloaded options by size with a quick db query, then flip the worst offenders. A 40 MB autoload payload silently drops to 2 MB and the site feels like it just got new hardware.

7. wp transient delete --all when caches lie

Transients are supposed to expire on their own. In practice, on busy sites with weird plugin interactions, they pile up and start serving stale data long past their welcome. Nuke them all.

wp transient delete --all

This is the second thing I try after wp cache flush, when a client swears the front end is wrong and I cannot reproduce it locally. Often the issue is a stale transient holding onto last week's homepage query results.

8. wp eval-file for one-off PHP with the WP runtime loaded

Sometimes I need to do something that no command covers. Maybe I want to loop over every post and check a custom field against an external API. Maybe I want to manually trigger a function buried in a plugin. wp eval-file runs an arbitrary PHP file with WordPress fully bootstrapped, so I can use any function or hook I want.

wp eval-file fix-orphaned-orders.php

The script just writes plain PHP, calls get_posts() or whatever I need, and exits. It is the escape hatch for the 5% of jobs that do not fit a built-in command. I keep a folder of these little scripts around and pull from it whenever a similar job comes up again.

One last thing

Install WP-CLI on every server you touch. Even if you never use it, future-you will thank present-you. The day a client calls in a panic because the admin will not load is a bad day to learn how to install CLI tools on a server you barely remember provisioning.