Roll Back Plugin

This is the ability this plugin had no answer for. plugins/update-plugin only applies an update WordPress.org is already offering, and plugins/install-plugin installs the latest. So once a plugin was on 4.3.5, there was no route back to 4.3.1 — the single most common need after a bad update.

versions/rollback-plugin moves an installed plugin onto any version WordPress.org published, in either direction. Settings and database content are untouched, and an active plugin comes back active.

At a glance

Abilityversions/rollback-plugin
ToolsetWP Rollback — toolset/wp-rollback
GroupVersion Targeting › Rollback
RequiresNothing. WP Rollback is optional and adds local archives only
Capabilitymanage_options and update_plugins
SafetyDestructive — replaces the plugin’s files. Requires confirm: true
RepeatableIdempotent — asking for the same version twice leaves the same files
HonoursDISALLOW_FILE_MODS
Ships inAcrossAI Abilities Manager 0.0.45 and later

How it works

It drives WordPress core’s own Plugin_Upgrader rather than a third-party rollback plugin, and that choice is what makes it safe. Since WordPress 6.3 the upgrader moves the existing copy aside before applying a package and restores it on shutdown if the package fails — immune to PHP timeouts. That is the hard part of a rollback, already written and already tested by WordPress itself.

The whole move happens inside one request, behind maintenance mode, so visitors never hit a half-written plugin.

Packages come from WordPress.org first. If this site holds a local archive of the version — which WP Rollback keeps for versions it has installed before — that is used as a fallback, and the response says which source was applied. The directory’s copy is preferred because it is canonical and can be checked afterwards; an archive is whatever this site happened to keep.

Input

NameTypeRequiredWhat it is
pluginstringYesPlugin file, folder name, display name or partial match.
versionstringYesThe version to move to. Older or newer. versions/list-asset-versions returns the valid values.
confirmbooleanYes, in practiceMust be true. Without it the ability refuses and explains why.

What comes back

NameTypeWhat it is
previous_versionstringWhat it was on before.
versionstringWhat it is on now.
relationstringolder or newer — whether this was a downgrade.
changedbooleanFalse when the plugin was already on that version; nothing was touched.
package_sourcestringwordpress.org or local_archive.
was_active / reactivatedbooleanWhether it was active before, and whether it came back. An overwrite deactivates a plugin as a side effect nobody asked for.
warningsarrayNotably, that a downgrade will be offered again at the next update check.
verify_hintstringSays the files were replaced, not verified, and names the ability that verifies them.
blocked_reasonstringconfirmation_required when confirm was omitted.

Example

Ask your assistant:

That last Akismet update broke my contact form — put it back on 5.7.1.

{
  "ability": "versions/rollback-plugin",
  "parameters": {
    "plugin": "akismet",
    "version": "5.7.1",
    "confirm": true
  }
}

Worth knowing

  • A downgrade does not stick by itself. WordPress will offer the newer version again at the next update check, and an automatic update can undo it. Disable updates for that plugin if the older version must hold.
  • Asking for the version already installed is reported as success with changed: false, and points at plugins/reinstall-plugin — which is what you want if the goal was repairing files rather than moving version.
  • Settings and database content survive. A plugin’s data lives in the database, not in its folder.
  • Run versions/check-asset-rollback first on a multisite — a network-activated plugin moves for every site at once.
  • If the old version cannot be activated afterwards, the response says so rather than leaving a silently deactivated plugin looking like a crash.

Related abilities


Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager

Browse the rest: Every ability, by category


Keep reading