Preview with the dry run option, then update patch releases first, then minor ones, excluding plugins that need manual testing. WP-CLI supports all three, plus an exclude list and a target version. Updating in small steps keeps the blast radius small when a release goes wrong.
The options that matter
The WP-CLI handbook documents the plugin update command with these relevant options:
| Option | Effect |
|---|---|
| all | Update every plugin that has an update |
| exclude | Skip a comma separated list of plugin names |
| minor | Only minor releases, for example 1.3 to 1.4 |
| patch | Only patch releases, for example 1.3 to 1.3.3 |
| version | Update to a specific version |
| dry-run | Preview which plugins would be updated |
| include-vcs | Include plugins under version control, which are skipped by default |
By default, plugins under git, svn or similar are skipped, which protects work in progress on custom plugins.
A safer sequence
- Take a backup and note current versions with the list command.
- Run a preview.
- Apply patch updates to everything except sensitive plugins.
- Smoke test.
- Apply minor updates on staging, then production.
- Handle major releases one at a time, with a rollback path.
wp plugin update --all --dry-run
wp plugin update --all --patch --exclude=woocommerce
The exclude name above is only an example of a plugin you might handle separately.
Why patch first
Semantic versioning is a convention, not a guarantee, and authors differ on how strictly they follow it. Patch releases are usually the smallest change, which makes them the lowest risk starting point, but test anyway for plugins that touch payments, forms or login.
Handling the exceptions
Some plugins deserve their own path: checkout, membership, and anything with custom code layered on top. For these, update on staging, run the specific flow (a test purchase, a login), and then promote. Our post on updating store plugins with a rollback plan gives a template.
Record what you did
Save the command output with the date. If a client asks what changed last Tuesday, you can answer in a minute. The output also lists each download source, which is useful evidence if you need to show that updates came from the directory.
One more point from the handbook: an insecure option exists to retry downloads without certificate validation. It makes requests vulnerable to a man in the middle attack, so do not use it in scripts.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fixed version is matched to the affected component.
Common mistakes
Running the update across every site at once is the main one. Start with one low-risk site and wait a day. Another is forgetting that auto-updates may already be changing versions between your runs, so always capture the list before and after. A third is skipping the smoke test because the command printed success. A success line means the files were replaced, not that the checkout still works.
Quick check
Does dry run change anything?
No. It only previews which plugins would be updated.
Why are some plugins skipped?
Plugins under version control are skipped by default unless you set the include option.
Sources
Last reviewed: 19 October 2026.
