Skip to main content

WP-CLI: Managing WordPress from the Command Line

WordPress · 19.04.2026 · 5 min read
Illustration for “WP-CLI: Managing WordPress from the Command Line”

WP-CLI is the official command-line tool for WordPress. It lets you manage plugins, themes, users, and the database directly from SSH, without a browser.

Installing WP-CLI

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

# Check
wp --version
# WP-CLI 2.10.0

Basic commands

Updates

# Update WordPress core
wp core update

# Update all plugins
wp plugin update --all

# Update all themes
wp theme update --all

# Update everything at once
wp core update && wp plugin update --all && wp theme update --all

Plugins and themes

# Install a plugin
wp plugin install wordfence --activate

# Deactivate a plugin
wp plugin deactivate contact-form-7

# List plugins
wp plugin list

# Delete a plugin
wp plugin delete hello-dolly

Users

# Create an administrator
wp user create admin2 admin2@example.com --role=administrator --user_pass=SecurePass123!

# Change a password
wp user update admin --user_pass=NewPassword456!

# List users
wp user list --role=administrator

Database

# Export the database
wp db export backup-$(date +%Y%m%d).sql

# Import the database
wp db import backup.sql

# Search and replace a URL (during migration!)
wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables
💡 wp search-replace automatically handles serialized PHP data — safer than a manual SQL UPDATE.

Useful commands for debugging

# Flush the cache
wp cache flush

# Regenerate thumbnails
wp media regenerate --yes

# Check and repair the database
wp db check
wp db repair

# Get/set an option
wp option get siteurl
wp option update blogname "My Site"
CommandWhat it does
wp core updateUpdates WP to the latest version
wp plugin update --allUpdates all plugins
wp db exportBacks up the database
wp search-replaceChanges the URL during migration
wp cache flushClears the cache

Common WP-CLI mistakes

Almost every WP-CLI error comes down to three causes: the wrong path, root permissions, and CLI running a different PHP than the web server.

Error: This does not seem to be a WordPress installation.

WP-CLI looks for the wp-load.php file in the current directory and upward through the tree. If the command runs from outside the site root, point it there explicitly: wp --path=/var/www/example.com/public_html core version.

Error: YIKES! It looks like you're running this as super user (root).

WP-CLI blocks running as root by default — files created as root break ownership for the PHP-FPM user. If you fully understand the risk (say, inside a single-user container), add the --allow-root flag. Otherwise switch to the site's own user: sudo -u www-data wp core version --path=....

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

Running wp search-replace on a large database (tens of thousands of postmeta rows) hits the PHP CLI memory limit — it's set separately from the web server's PHP limit, in its own CLI-mode php.ini. Raise the limit temporarily: php -d memory_limit=512M $(which wp) search-replace ....

WP-CLI or wp-admin: when to use which

TaskWP-CLIwp-admin
Bulk-updating 50+ pluginsSeconds, one scriptClick each one, or Bulk actions in the browser
A one-off text edit on a pageAwkwardFaster
Automation in CI/CDOnly optionNot available
Working with the frontend downAlways worksUnavailable during a critical site error

WP-CLI's main advantage is that it talks to WordPress Core directly, bypassing HTTP and the browser, so it still works when the site shows a white screen or a 500 error.

When WP-CLI doesn't fit

Some shared hosting plans don't provide SSH access at all — WP-CLI is physically unavailable there; see SSH access on cPanel hosting to check which plans support it. On some setups, PHP CLI and the web server's PHP are different binaries with different versions and php.ini settings: a command might run fine under PHP 8.3 in CLI while the site itself runs on PHP 7.4 on the web, and behavior can differ. For a one-off edit to a single page or checking one plugin, opening wp-admin is almost always faster than recalling command syntax.

How to verify the result

After bulk changes via WP-CLI, check more than "the command finished without errors" — check the site's actual state:

# Check that WordPress is installed and reachable
wp core is-installed; echo "Exit code: $?"

# General environment info
wp cli info

# Check site state after bulk changes
wp plugin list --status=active
wp option get siteurl

An exit code of 0 after wp core is-installed confirms the installation is intact. A non-zero code in an automation script is a signal to stop and not run the next steps (like a deploy) against a broken site.

Was this article helpful?
← Back to Knowledge Base Ask Support