Essential WP-CLI Commands for Managing WordPress from the Terminal

When the WordPress Dashboard Eats Your Time

It's 3 AM and your site is down with a "Error establishing a database connection" message. To fix the issue, you need to disable a plugin, but even the login page to the dashboard won't load. Or maybe you have 200 articles and need to change the domain address in all of them from example.com to example.ir. From the dashboard, that means 200 manual edits. With WP-CLI, both tasks are done in less than a minute.

WP-CLI is a command-line tool that makes almost everything you do from the WordPress dashboard — and many other things you can't do from the dashboard — possible from the terminal. This article is for an administrator who is currently dealing with one of these problems, not for someone looking for a "general overview."

Installing and Checking WP-CLI Health

Most Linux hosts today come with WP-CLI pre-installed. First, check:

wp --info

If the output includes the PHP version and the WordPress installation path, you're ready. If not, install it:

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

After installation, check the version:

wp --version

The output should look something like WP-CLI 2.11.0. If the version is older than 2.8, upgrade it; older versions have issues with PHP 8.2 and above.

An important note: WP-CLI must be run as the same user that owns the WordPress files. If you run it as root, the files it creates will be owned by root, and later you'll encounter "permission denied" errors when uploading or editing from the dashboard. Here's where people go wrong: they run the site as the www-data user but invoke WP-CLI as root. The result? A day later, a plugin that needs updating can't be updated, and no one understands why.

Updating Core, Plugins, and Themes from the Command Line

Updating from the dashboard is risky when your site has real traffic: the page gets refreshed mid-process, the connection drops, and it's left incomplete. From the terminal, first take a backup, then update.

To update everything — core, plugins, themes, and translation files — a single command is enough:

wp core update
wp plugin update --all
wp theme update --all
wp language core update

If you just want to see what has updates available, without changing anything:

wp plugin list --update=available

The output shows a table indicating which plugins have new versions and what the current version of each is. Run this command before any major update to make sure the plugin you're about to update is compatible with your PHP version.

A tip many people don't know: if your site uses managed WordPress hosting, automatic updates might be handled by the host, and running wp core update manually may result in an "Another update is already in progress" error. In this case, wait for the host's process to finish, then run the command.

Search and Replace in the Database

Changing domains, migrating from HTTP to HTTPS, or moving a site from a development environment to a production server — all these share a common need: replacing a string across all database tables. From the dashboard, this is either impossible or requires heavy plugins.

The main command is:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --precise

The --all-tables flag means all tables, not just WordPress's default ones. The --precise flag ensures replacement only happens on exact strings, not substrings. Without this flag, if your string is example.com and www.example.com also exists in the database, the result will be corrupted.

Before running the actual command, test with the --dry-run flag:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --dry-run

This command only reports the number of found instances without changing anything. The number you see should match your expectations. If it's zero, you've typed the string incorrectly or you're replacing the wrong domain.

A serious warning: if your site uses Object Cache — for example, Redis — you must clear the cache after search-replace. Otherwise, the site will serve old content from the cache and you'll think the command didn't work. The command to clear the cache with WP-CLI:

wp cache flush

Common Error in search-replace

The most common error I've seen is someone running wp search-replace on a live site's database without a backup, and then realizing that the string they replaced also existed in article content that shouldn't have been changed. For example, replacing example.com with example.ir might also alter text in an article written about "the difference between example.com and example.org." The solution: always take a backup first, then test with --dry-run, and if in doubt, use the --include-columns flag to only change specific columns like post_content.

Resetting a User's Password from the Terminal

A user has forgotten their password, and the recovery email went to the spam folder. Or an admin account has been hacked and you need to change the password quickly. You can't log in from the dashboard. WP-CLI does this in one line:

wp user update 1 --user_pass='YourNewStrongPassword'

The number 1 is the admin user's ID. If you don't know whose ID it is, first view the user list:

wp user list --fields=ID,user_login,roles

This command shows a table of which user has what role. After the reset, tell the user to use the "Lost your password?" option on the login page so they can choose a new password themselves. The password you set is only for initial login.

If you want to create a new user with the administrator role:

wp user create john john@example.com --role=administrator --user_pass='TempPass123'

After creation, make sure to ask the user to change the password. Never leave them with a temporary password that's sitting in the server's terminal history.

Deactivating a Plugin That Has Taken Down Your Site

The site has thrown a fatal error (WSOD) and the page is white. There's no way through the dashboard. With WP-CLI, you can deactivate all plugins at once:

wp plugin deactivate --all

The site comes back. Now activate them one by one to find the culprit:

wp plugin activate woocommerce

After each activation, check the site. If the error returns, that plugin is the culprit. This diagnostic method is much faster than looking at logs, especially when the error isn't recorded in the logs.

If you only want to deactivate one specific plugin:

wp plugin deactivate akismet

Managing Cron and Automatic Cleanup

WordPress runs scheduled tasks through its own cron system. When the site is busy, these cron jobs might not run or might run multiple times. With WP-CLI, you can see what events are in the queue:

wp cron event list

If an event is stuck and keeps running, delete it:

wp cron event delete event_name

To manually run all due events:

wp cron event run --due-now

This command is especially useful after migrating a site to a new server, as old cron jobs might still point to the previous domain.

Here's Where They Go Wrong: Running WP-CLI from the Wrong Directory

The biggest mistake I see in practical WP-CLI work is an administrator running the command from a directory other than the WordPress root. For example, running wp plugin list from /home/user and getting the error "Error: This does not seem to be a WordPress installation." The solution is simple: either navigate to the WordPress directory (cd /var/www/html) or use the --path flag:

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

If your site is installed in a subdirectory — for example, example.com/blog — and you want to run commands from the root, make sure to pass --path pointing to the subdirectory path. Otherwise, WP-CLI will think the site root is where you are and throw an error.

Quick Backup Before Any Dangerous Operation

Before any search-replace or major update, take a database backup. With WP-CLI, this is one line:

wp db export /backup/site-$(date +%Y%m%d).sql

This command saves the SQL file with the date in its name. If something breaks, restore it:

wp db import /backup/site-20250615.sql

Backing up files is also important, but WP-CLI only manages the database. For files, use rsync or similar tools. A good habit: before every core update, back up both the database and the wp-content files. After the update, if you see an error, restore and solve the problem in a test environment.

WP-CLI on Shared Hosting

If you're on shared hosting and WP-CLI isn't pre-installed, you can keep the phar file in your own directory and run it with PHP:

php wp-cli.phar plugin list

This method is slightly slower but it works. The main limitation of shared hosting is that some commands like wp core download might not run due to memory limits or timeouts. In this case, either ask your host to install WP-CLI, or perform heavy tasks on a dedicated Linux host. If you're planning to migrate your site, check out ServerNet's documentation and knowledge base.

Automation with WP-CLI

Once you've learned the commands, the next step is automation. A simple bash script that runs weekly and applies updates:

#!/bin/bash
cd /var/www/html
wp db export /backup/weekly-$(date +%Y%m%d).sql
wp plugin update --all
wp theme update --all
wp core update

Run this script with cron. But before that, an important note: automatic plugin updates can break your site if a plugin is incompatible with the new PHP or WordPress version. My recommendation: automate core updates, but manually review plugins once a week. If you have a critical plugin — like a payment gateway — never include it in automatic updates.

For monitoring site health after updates, uptime monitoring tools can alert you if a site goes down. Check out the website uptime monitoring guide to set up outage alerts without false positives.

Troubleshooting with WP-CLI

When your site throws errors but the logs show nothing, WP-CLI can provide detailed information:

wp db check

This command checks the database health. If a table is corrupted, it will report it. To check PHP settings:

wp eval 'echo ini_get("memory_limit");'

This command shows the memory_limit value. If your site is facing an "Allowed memory size exhausted" error, check this number. The recommended value for modern WordPress is at least 256M.

To view PHP error logs in real-time:

wp debug

This command shows recent logs and can find the problem much faster than searching through files.

Practical Summary

WP-CLI is a tool that, once you master it, you'll stop using the dashboard for administrative tasks. Updates, search-replace, password resets, deactivating broken plugins — all done in seconds from the terminal. The cost? A day of learning and getting used to the command line. If you've never worked with a terminal, there's a bit of a learning curve, but it's worth it.

The first thing you should do: on a test site — not your main site — run the wp plugin list command and look at the output. Then try wp db export and open the SQL file. Once you're comfortable with these two commands, the rest is simple.

If your site is on a host that doesn't have SSH, or WP-CLI isn't installed, ask your host to install it. If they won't, it's time to change hosts. A tool that reduces your daily work from an hour to a minute is your right, not a privilege.

Frequently Asked Questions

What is WP-CLI and what is it used for?

WP-CLI is a command-line tool for managing WordPress. With it, you can perform updates, backups, user management, database search and replace, and many other tasks without needing a browser.

Does WP-CLI work on shared hosting?

It depends on the host. Some shared hosts have WP-CLI pre-installed. If they don't, you can download the phar file and run it with PHP, but some heavy commands may face resource limitations.

How do I change the admin password with WP-CLI?

Run the command wp user update 1 --user_pass='NewPassword' from the WordPress root directory. The number 1 is the admin user's ID. If you don't know whose ID it is, first run wp user list.

Can WP-CLI damage my site?

WP-CLI itself doesn't damage your site, but commands like search-replace can corrupt data if run without a backup and testing. Always take a backup before dangerous operations and test with the --dry-run flag.