WP-CLI (~5.1k stars on the framework repo) is the official command-line interface for WordPress. If your workflow still relies only on clicking through wp-admin, you are leaving hours on the table every migration, deploy, and content operation. WP-CLI wraps WordPress bootstrap in terminal commands — scriptable, automatable, and repeatable in ways the admin UI never will be.

What WP-CLI solves

WordPress administrators live in browsers: install plugins, run updates, export databases, create users. Developers and DevOps engineers need the same power without HTTP timeouts, without clicking through twelve screens, and with output they can pipe into logs or CI artifacts. WP-CLI provides:

  • Core, plugin, and theme management from the shell
  • Database operations (export, import, search-replace)
  • User and role management
  • Option and transient manipulation
  • Cron execution and cache flush helpers
  • Extensibility via custom commands in plugins and themes

Who needs WP-CLI

  • Developers on Bedrock or any Git-driven WordPress project
  • Agencies running staging → production promotion weekly
  • Anyone who has ever needed search-replace across all tables after a domain change
  • CI pipelines that install WordPress, run tests, and deploy artifacts

When NOT to rely on CLI alone

  • Non-technical editors updating marketing copy in ACF — they need a GUI like Quickfields Bulk Editor for ACF
  • Shared hosting without SSH — WP-CLI may be unavailable or restricted
  • One-off visual tweaks — the Customizer or Site Editor is faster
  • Dangerous production experiments — CLI power requires discipline; always backup first

Installation

Bash
# Download phar (see wp-cli.org for latest)
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

Many local tools (DDEV, Lando, SpinupWP) ship WP-CLI preinstalled. On Bedrock, run commands from the project root where wp-cli.yml points at the correct WordPress install.

Everyday commands worth memorizing

Bash
wp core download
wp plugin install query-monitor --activate
wp theme list
wp search-replace 'https://old.test' 'https://new.test' --all-tables
wp user create editor editor@example.com --role=editor
wp db export backup.sql
wp cache flush
wp cron event list

Where WP-CLI shines

  • Local → staging → production URL rewritessearch-replace with dry-run first
  • Scripted plugin/theme installs in CI — reproducible environments for QA
  • Bulk user or post operations — without admin UI timeouts on large tables
  • Database exports before risky updates — one command, timestamped file
  • Cron debugging — list and run scheduled events when traffic is low
  • Generating wp-config salts — during Bedrock or classic setup

Typical deploy workflow with WP-CLI

  1. Pull latest Git artifact on staging.
  2. composer install --no-dev on Bedrock projects.
  3. wp core update-db if core version changed.
  4. wp plugin update --all or Composer-driven updates per your policy.
  5. wp search-replace if domain differs (dry-run, then execute).
  6. wp cache flush and smoke-test critical paths.
  7. Install Query Monitor on staging only to verify query counts.

WP-CLI vs admin bulk tools

TaskWP-CLIwp-admin GUI
Domain migration search-replaceIdealPlugins exist, slower
ACF copy editing across 50 pagesRequires custom scriptsQuickfields sheet ideal
Plugin activate/deactivateBoth workCLI scriptable
Media library browsingPoor fitAdmin wins

CLI is perfect for infrastructure and migrations. Product managers updating ACF marketing copy usually need a spreadsheet GUI. That is why we built Quickfields as a sheet in wp-admin — complementary to WP-CLI, not a replacement. Pro: Quickfields Pro.

Custom commands and packages

Plugins can register wp my-plugin sync style commands. Community packages extend WP-CLI for imports, media regeneration, and more. Check wp-cli/wp-cli and the package index for maintained extensions before writing your own.

Gotchas

  • Wrong directory — WP-CLI must run where WordPress is installed; Bedrock uses wp-cli.yml to redirect.
  • search-replace on serialized data — use WP-CLI's built-in handling; naive sed breaks options.
  • Production writes — require backups; treat --yes flags carefully in scripts.
  • File permissions — CLI runs as the SSH user; uploads may need chown fixes after imports.

FAQ

Is WP-CLI official? Yes — maintained by the WP-CLI project with broad hosting support.

Works with multisite? Yes with --url for site context.

Replace wp-admin entirely? No — editors still need admin for content; developers use both.

Multisite network activate? Use wp plugin network activate with care — test on staging networks first.

Bedrock path issues? Ensure wp-cli.yml path points to web/wp and vendor autoload if your project uses it.

Real-world scenarios where WP-CLI saves a sprint

Client domain change after HTTPS migration: dry-run wp search-replace 'http://old.com' 'https://new.com' --all-tables, inspect diff, execute, then flush caches. Spinning up a reviewer environment: script wp db import, wp user update passwords, wp plugin deactivate for payment gateways. Post-deploy smoke automation: chain wp core is-installed, wp option get siteurl, and HTTP health checks in CI. None of these replace editorial tools — when marketing needs to rewrite hero copy on 35 location pages, point them at Quickfields or Quickfields Pro while you handle infrastructure via CLI.

Keep a project-specific wp-commands.md in your repo documenting the exact search-replace pairs, plugin slugs, and cron fixes your stack needs — future you and contractors will not have to rediscover them from shell history.

For automated nightly backups on managed hosts, combine wp db export with your provider's snapshot schedule — WP-CLI excels at the WordPress-specific half of that equation.

Repo

github.com/wp-cli/wp-cli