WP-CLI commands you will use daily: a step-by-step guide

Managing WordPress from the terminal saves hours each week

When you're managing multiple WordPress sites or handling bulk operations, clicking through the admin interface becomes a bottleneck. WP-CLI commands you will use daily: a step-by-step guide—these aren't obscure shell tricks, they're the practical tools that let you scale workflows and handle migrations without breaking a sweat. We'll walk through the commands that solve real problems every developer encounters.

Getting started with WP-CLI

Before diving into specific commands, make sure WP-CLI is installed on your server or local environment. You can verify this by running:

wp --version

If you don't have it installed, grab it from wp-cli.org. Once installed, all commands run from your WordPress root directory. WP-CLI connects to your WordPress installation through wp-config.php, so you need filesystem access and database credentials to work.

Installing and activating plugins with wp plugin

The wp plugin install and wp plugin activate commands replace the tedious download-upload-activate cycle. This is especially valuable when provisioning new sites or standardizing plugin stacks across environments.

Real scenario: You need to install WooCommerce, the Advanced Custom Fields plugin, and Gravity Forms on a fresh staging environment. Instead of logging into the admin, navigating to Plugins, searching, uploading, and activating each one manually, you run:

wp plugin install woocommerce --activate
wp plugin install advanced-custom-fields --activate
wp plugin install gravityforms --activate

Each command downloads from the WordPress plugin directory, installs it to /wp-content/plugins/, and activates it in one go. If you're installing a commercial or custom plugin from a ZIP file instead, use:

wp plugin install /path/to/plugin.zip --activate

You can also bulk-install multiple plugins at once without repetition:

wp plugin install woocommerce advanced-custom-fields jetpack akismet --activate

For managing existing plugins, wp plugin list shows their status, and wp plugin deactivate or wp plugin delete handle cleanup. This approach is particularly useful in CI/CD pipelines where you need reproducible site configurations across staging and production.

Database migrations with wp search-replace

When you move a WordPress site between domains or environments, URLs hardcoded in the database break. The wp search-replace command fixes this instantly, updating all serialized data and attachments correctly—something a simple SQL find-and-replace can't handle reliably.

Real scenario: You've developed a site locally at http://localhost:3000 and need to push it to the staging server at https://staging.client.com. The database contains hardcoded URLs in posts, custom fields, and theme options. Running a raw SQL query risks breaking serialized PHP objects. Instead:

wp search-replace 'http://localhost:3000' 'https://staging.client.com'

WP-CLI automatically:

• Updates post content and meta fields
• Fixes serialized data (so PHP unserialize still works)
• Updates attachment URLs
• Handles theme and plugin options

You can preview changes before committing with the --dry-run flag:

wp search-replace 'http://localhost:3000' 'https://staging.client.com' --dry-run

This shows you exactly how many replacements will happen without modifying anything. Only run the actual command once you've verified the output. For more precise control, target specific tables:

wp search-replace 'old-url.com' 'new-url.com' wp_posts wp_postmeta --dry-run

This is invaluable during client handoffs, multi-environment deployments, and any time you're syncing databases across development, staging, and production.

Exporting and importing databases with wp db

The wp db export and wp db import commands handle database backups and restoration without relying on phpMyAdmin or manual mysqldump calls. They're faster, more reliable, and integrate cleanly into deployment scripts.

Real scenario: You're about to deploy a risky plugin update to production. Best practice is to create a backup first. Instead of SSH-ing into the database server and running mysqldump manually:

wp db export backup-before-update.sql

This creates a SQL dump in your current directory with the database name, date, or any custom prefix you specify:

wp db export ~/backups/prod-$(date +%Y%m%d-%H%M%S).sql

If something goes wrong and you need to restore, use:

wp db import ~/backups/prod-20240115-143022.sql

For large databases, you can compress the export to save disk space:

wp db export - | gzip > backup.sql.gz

And decompress before importing:

gunzip -c backup.sql.gz | wp db import -

This approach works beautifully in deployment pipelines where you want to back up production before pushing code changes, then quickly roll back if needed. It also enables pulling production data to staging for testing without exposing sensitive information (you'd typically run search-replace afterward to change URLs).

Manually triggering cron events with wp cron

WordPress uses its own cron system to schedule tasks like publishing scheduled posts, sending email notifications, or running custom cleanup routines. Unlike system cron, WordPress cron only triggers when the site receives traffic. In low-traffic environments or when you need immediate execution, wp cron event run lets you manually fire specific events.

Real scenario: Your client's email notification system runs on WordPress's scheduled event send_pending_notifications. The task should run every hour, but in production it sometimes stalls for days if traffic drops. Rather than troubleshooting WordPress cron reliability, you can set up a true system cron to invoke the event via WP-CLI:

First, list all registered cron events to find the exact hook name:

wp cron event list

You'll see output like:

Now manually trigger the event:

wp cron event run send_pending_notifications

To set this up with system cron, add to your server's crontab:

0 * * * * cd /var/www/wordpress && wp cron event run send_pending_notifications

This runs every hour at the top of the hour, guaranteeing execution regardless of traffic. You can test it immediately without waiting for the next scheduled run. For debugging, add a verbose flag to see execution details:

wp cron event run send_pending_notifications --verbose

This approach solves the common problem of unreliable WordPress cron in production environments where you need guaranteed task execution.

Common mistakes to avoid

Forgetting to use --dry-run with search-replace: A mistyped search-replace command can corrupt your entire database. Always preview with --dry-run first. Yes, always.

Running WP-CLI commands from the wrong directory: WP-CLI needs to be executed from your WordPress root directory (where wp-config.php lives). If you're in a subdirectory, use --path:

wp --path=/var/www/wordpress plugin list

Assuming serialized data will survive manual SQL edits: This is why search-replace exists. PHP serialized data stores string lengths, so if you manually change a URL in the database, the length becomes incorrect and unserialize fails. WP-CLI handles this automatically.

Not backing up before running destructive commands: Before deleting plugins, themes, or running search-replace in production, export your database first. It takes 10 seconds and saves hours of panic recovery.

Overlooking environment-specific configurations: WP-CLI uses your wp-config.php credentials. If you're running commands via SSH on a production server, make sure the database host and credentials in that file are for production, not your local machine. Double-check before executing.

Key takeaways

• wp plugin install and wp plugin activate automate plugin provisioning—especially useful in CI/CD pipelines and multi-site setups
• wp search-replace safely updates URLs and handles serialized data that raw SQL cannot, making migrations between environments reliable
• wp db export and wp db import replace manual mysqldump workflows for faster backups and restoration in deployment scripts
• wp cron event run gives you manual control over scheduled tasks, enabling reliable execution via system cron instead of relying on WordPress cron
• Always use --dry-run before destructive operations and keep your working directory aligned with your WordPress root