How to update WordPress plugins with WP-CLI

Updating WordPress plugins with WP-CLI keeps routine maintenance in the shell, which is useful on servers without dashboard access and during controlled change windows where the exact plugin slug matters. The command-driven path also makes it easier to preview pending updates, back up the site first, and apply the same workflow across more than one WordPress install.

The wp plugin update command reads the current site state from the WordPress document root, checks installed plugin versions against the versions available from the official plugin source, and then replaces the plugin files for the selected slugs. It can target one plugin directly, preview the result with –dry-run, or process a broader batch when the maintenance plan allows it.

Plugin updates are write operations that can change code, database behavior, editor screens, or frontend output immediately. Run the command as the account that owns the WordPress files, create a rollback point before touching production, and keep installation or automatic-update policy in separate procedures instead of expanding a maintenance window ad hoc.

Steps to update WordPress plugins with WP-CLI:

Change into the exact WordPress document root before running the update command.
```
$ cd /var/www/example.com/public_html
```
Related: How to use WP-CLI safely on a production WordPress site

List the installed plugins and confirm which slugs actually have updates pending.

$ wp plugin list --fields=name,status,update,version,update_version
name            status    update     version  update_version
akismet         inactive  none       5.6
classic-editor  inactive  available  1.6.5    1.6.7
hello           inactive  none       1.7.2
google-site-kit active    none       1.175.0

The update and update_version columns are the quickest way to catch a single pending plugin before a broader batch command touches more than intended.

Export a database backup before updating plugin files on a live site.

$ wp db export ~/backups/wordpress/pre-plugin-update.sql
Success: Exported to '/home/user/backups/wordpress/pre-plugin-update.sql'.

Preview the pending change before writing new plugin files.
```
$ wp plugin update classic-editor --dry-run
Available plugin updates:
name            status    version  update_version
classic-editor  inactive  1.6.5    1.6.7
```
For a broader maintenance window, preview the same job with wp plugin update --all --dry-run --exclude=plugin-slug when one plugin must stay pinned.

Update the target plugin by slug once the preview and backup are in place.

$ wp plugin update classic-editor
Downloading update from https://downloads.wordpress.org/plugin/classic-editor.1.6.7.zip...
Installing the latest version...
Plugin updated successfully.
name            old_version  new_version  status
classic-editor  1.6.5        1.6.7        Updated
Success: Updated 1 of 1 plugins.

When the maintenance window covers every pending plugin, the batch form is wp plugin update --all or wp plugin update --all --exclude=plugin-slug.

Re-check the plugin list and confirm that the update is no longer pending.

$ wp plugin list --fields=name,status,update,version,update_version
name            status    update  version  update_version
akismet         inactive  none    5.6
classic-editor  inactive  none    1.6.7
hello           inactive  none    1.7.2
google-site-kit active    none    1.175.0

Test the affected admin screen or public feature that depends on the updated plugin before closing the maintenance window.

Plugin file updates can succeed while the site still fails on the next request because of changed settings, PHP compatibility, or a dependent add-on. If the updated plugin causes an outage, disable it quickly and restore the rollback point.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.