๐ฃ๐ถ๐ป๐ฝ๐ผ๐ถ๐ป๐ ๐ฅ๐ผ๐น๐น๐ฏ๐ฎ๐ฐ๐ธ ๐ช๐ถ๐๐ต ๐ช๐ฃ-๐๐๐
You update 20 plugins at once. One plugin breaks your site.
Most tools roll back all 20 updates to keep things safe. This is a standard approach. However, you often want to keep the 19 working updates and only revert the one broken plugin.
You can build this logic using WP-CLI.
The core command is:
wp plugin install
Here is what these flags do:
โข --version=1.2.3: Installs a specific older version from WP.org. โข --force: Overwrites the current plugin files. โข --skip-plugins --skip-themes: Prevents WP-CLI from loading broken code during the process.
To make this work, you must change your update strategy. Do not update in bulk. Update one plugin at a time and check the site status after each step.
Follow this workflow:
- Check site health: GET / returns 200 OK.
- Update one plugin: wp plugin update
. - Check site health again.
- If the site returns a 500 error, that plugin is the cause.
- Roll back that specific plugin using the install command with the previous version.
- Verify the site is back to 200 OK.
- Move to the next plugin.
To automate this, save a list of your current versions before you start: wp plugin list --format=json --skip-plugins --skip-themes > /tmp/plugins_before.json
You can use jq to pull the exact version number of the failed plugin from this file.
This method has three main advantages:
- You know exactly which plugin caused the error.
- You do not lose the successful updates from other plugins.
- You only need to retry the failed plugin later.
One warning: rolling back files does not always fix a site. If a plugin changed your database schema, replacing the files will not help. If the site stays broken after a rollback, you must move to a full database restore.
Per-plugin rollback is more complex to build than bulk rollback. But it provides much better control over your production environment.
Source: https://dev.to/susumun/pinpoint-rollback-building-per-plugin-revert-with-wp-cli-5go5