You batch-update 20 plugins, and one breaks the site. Most WordPress maintenance tools play it safe and roll back all 20 updates (variations on "Safe Updates" or "Atomic Updates"). It's a reasonable default.

But running in production, you start running into cases where you want only the broken one reverted, and the other 19 to keep their updates. Here's how that design is built on top of WP-CLI.

The command that makes it possible — wp plugin install --version=X --force

WP-CLI has a powerful command for "install a plugin at a specific version, overwriting whatever's currently there":

wp plugin install <plugin-slug> --version=1.2.3 --force --skip-plugins --skip-themes

What each flag does:

• --version=1.2.3 — Specifies the older version to install (any version published on WP.org works)
• --force — Overwrites if the plugin is already installed
• --skip-plugins --skip-themes — Skips plugin/theme loading at WP-CLI startup, so WP-CLI itself doesn't crash even when a broken plugin is present (covered in a separate post)

That one line is enough to roll back a single plugin to a known-good version. The remaining design question is when and under what conditions to invoke it.

Combining with HTTP checks

Step-by-step updates with HTTP status checks between each:

Pre-update:    GET / → 200
↓
wp plugin update <plugin-slug> --skip-plugins --skip-themes
↓
Post-update:   GET / → 500   ← broken!
↓
wp plugin install <plugin-slug> --version=<previous> --force --skip-plugins --skip-themes
↓
Post-rollback: GET / → 200   ← recovered
↓
proceed to the next plugin

By switching the update granularity from "everything at once" to "one at a time + HTTP check", you get clear visibility into which plugin caused the breakage.

Identifying the rollback target

The plugin you just updated is the prime suspect — by construction. This isn't possible with bulk updates: if multiple plugins are updated together and HTTP returns 500, you can't tell which one is responsible.

The advantage of one-at-a-time updates is that the moment the HTTP status changes, the plugin updated immediately before becomes the confirmed rollback target. No risk of accidentally reverting an unrelated plugin.

The previous version comes from a pre-update snapshot:

# Capture before updates start
wp plugin list --format=json --skip-plugins --skip-themes > /tmp/plugins_before.json

# Look up the previous version of the failed plugin
prev_version=$(jq -r '.[] | select(.name=="<slug>") | .version' /tmp/plugins_before.json)

That gives you the version string to feed back into wp plugin install --version=<prev>. Roll back, verify, proceed to the next plugin.

Verifying recovery — always re-check HTTP after a rollback

After rolling back, take the HTTP status again:

• ✅ Back to 200 → skip the update for this plugin, continue to the next
• ❌ Still 500 → the rollback didn't recover the site (the broken state is in the DB schema or other files, not just the plugin's PHP) → escalate to heavier recovery (full DB rollback, cache flush, theme fallback, etc.)

The lesson: don't assume rolling back the plugin always fixes things. --force overwriting only replaces files; DB-side inconsistencies need separate detection.

Takeaway — "roll back all" vs "roll back one"

The industry-mainstream "roll back everything" design is simpler to implement and errs on the safe side — and there are good reasons it's the default. On the other hand, the "roll back only the one that broke" design has these operational advantages:

• The culprit is recorded directly in the log
• Successful updates to other plugins are preserved
• At the next maintenance run, only the rolled-back plugin needs retrying

A trade-off: more implementation complexity, in exchange for higher operational transparency and continuity.

The small WP-CLI command --version=X --force is what makes this possible. For anyone considering maintenance automation on shared hosts where SSH + WP-CLI is available, this flag combo is worth committing to memory.

For the structural reasons the industry as a whole hasn't adopted per-plugin rollback, see also three gaps the WordPress maintenance industry still hasn't solved.