Manage WordPress Plugins with WP-CLI: List, Install, Update, Delete

This article is a localized edition of the Japanese original. Read the Japanese original

WP-CLI is the official tool for operating WordPress from the command line. With the wp plugin commands you can list, install, update and delete plugins without opening the admin screen. It is also a way to deactivate plugins when you cannot get into the admin screen. This article covers the commands you use most for plugin management, the order of work, and the caveats. Only options confirmed in the official WP-CLI documentation (as of October 2026) are included.

Preparation: make WP-CLI available

If WP-CLI is not installed, install the Phar file using the official steps. As of October 2026, the official handbook requires PHP 7.2.24 or later.

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

The nightly build is a development build, so use the stable release above on production servers. Installation is covered in more detail in Installing and using WP-CLI for WordPress.

Where and as whom to run it

• Run it in the WordPress installation directory (where wp-config.php is), or specify the path, as in --path=/var/www/html.
• Run it as the same user that owns the WordPress files. If you run it as root, the files it creates are owned by root, which later makes updates from the admin screen fail. WP-CLI refuses to run as root by default and will not run without --allow-root.

# Example when the files are owned by www-data
sudo -u www-data wp plugin list --path=/var/www/html

The examples below start with wp and assume you are the owning user and inside the WordPress directory.

List plugins and check their status

# All plugins (name, status, update availability, version, auto-update setting)
wp plugin list

# Only inactive ones
wp plugin list --status=inactive

# Only those with updates
wp plugin list --update=available

# Choose which fields to show
wp plugin list --fields=name,status,version,update_version

Valid values for --status are active, active-network, dropin, inactive and must-use. --update=available filters on the value of a list field (update).

The name column shown here is the plugin slug you pass to the commands that follow. It is not the display name but the directory name under wp-content/plugins/. Use these commands to check the detailed status of a single plugin.

wp plugin status akismet

# Exit code 0 if active; usable in shell script conditions
wp plugin is-active akismet && echo active

Install and activate

Plugins in the WordPress.org plugin directory are installed by slug. You can find the slug in the URL of the directory page (https://wordpress.org/plugins/<slug>/).

# Install and activate at the same time
wp plugin install akismet --activate

# Install a specific version
wp plugin install akismet --version=5.3

# Install from a local zip or a URL (for paid plugins, etc.)
wp plugin install /home/deploy/my-plugin.zip --activate

Activation and deactivation work as follows. To act on the whole network in a multisite, add --network.

wp plugin activate akismet
wp plugin deactivate akismet

--version=5.3 is just an example of the syntax. Check which version numbers are available in the list of previous versions under "Advanced View" on the plugin's WordPress.org page before you specify one.

Update plugins

Back up the database before updating. Back up files separately with your server's method or a backup plugin.

wp db export before-plugin-update.sql

Next, check what will be updated with --dry-run, then run the update.

# Only show what would be updated (does not update anything)
wp plugin update --all --dry-run

# Update a single plugin
wp plugin update akismet

# Update everything, excluding specific plugins
wp plugin update --all --exclude=woocommerce,elementor

# Update only within minor releases (x.Y) or patch releases (x.y.Z)
wp plugin update --all --minor
wp plugin update --all --patch

wp plugin update has no --force option. If something breaks after an update, you can go back by specifying an earlier version with --version (only versions distributed on WordPress.org).

wp plugin update akismet --version=5.3

Auto-update settings

You can also toggle the auto-update setting shown on the Plugins screen of the admin from WP-CLI.

wp plugin auto-updates status --all
wp plugin auto-updates enable akismet
wp plugin auto-updates disable --all

Running auto-updates is also covered in How to auto-update plugins with WP-CLI.

Delete vs. uninstall

There are two commands that remove a plugin, and they behave differently.

The uninstall routine, if the plugin provides one, removes the settings and database tables the plugin created. Use delete if you may reinstall and want to keep the data, and uninstall to clean up the data as well.

# Deactivate, then delete only the files
wp plugin deactivate akismet
wp plugin delete akismet

# Deactivate, run the uninstall routine and delete the files in one go
wp plugin uninstall akismet --deactivate

Neither has an undo command. Data removed by uninstall can only be restored from a database backup taken beforehand.

Recover by deactivating a broken plugin

If the screen goes blank after a plugin update or you cannot get into the admin screen, you can deactivate the offending plugin with WP-CLI. The broken plugin may also load and error out while WP-CLI runs, so add --skip-plugins and --skip-themes to run without loading plugins and themes.

# If you know the cause
wp plugin deactivate problem-plugin --skip-plugins --skip-themes

# If you don't, deactivate everything, then reactivate one at a time to find it
wp plugin list --status=active --field=name --skip-plugins --skip-themes > active-plugins.txt
wp plugin deactivate --all --skip-plugins --skip-themes

Saving the list of active plugins to a file before deactivating everything makes it easy to restore. After removing the cause, you can reactivate them all from the saved list (remove the offending plugin from the list first).

xargs wp plugin activate < active-plugins.txt

Check plugin files for tampering

Plugins distributed on WordPress.org can be checked against the official checksums.

wp plugin verify-checksums --all

Plugins not distributed on WordPress.org (paid or custom plugins) have no checksums and cannot be verified.

Work on several sites at once

In a multisite, you can pull the list of sites and run a command on each one. This is the same form as the example in the official documentation.

wp site list --field=url | xargs -I % wp plugin list --url=%

If you manage several separate WordPress installations, loop over them with different --path values or use WP-CLI's alias feature.

Summary

• Run commands from the WordPress directory as the user who owns the WordPress files
• List plugins with wp plugin list, filter with --status or --update=available, and pass the slug from the name column to later commands
• Back up with wp db export before updating and check the targets with --dry-run. Roll back with --version
• delete removes only files; uninstall also removes data through the uninstall routine
• When the site stops displaying, deactivate with --skip-plugins --skip-themes

Related articles:

• Installing and using WP-CLI for WordPress
• How to auto-update plugins with WP-CLI
• Managing WordPress multisite with the WP-CLI site command

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)