WordPress only ever moves forward. Once a plugin is on 4.3.5 there is no route back to 4.3.1 — which is the single most common thing you need after an update breaks a site.
versions/get-rollback-status is the call to make first. It reports what this site can and cannot re-version, states the two limits up front, and says what installing WP Rollback would add — so an assistant plans against the real constraints instead of discovering them halfway through.
At a glance
| Ability | versions/get-rollback-status |
| Toolset | WP Rollback — toolset/wp-rollback |
| Group | Version Targeting › Versions & Pre-flight |
| Requires | Nothing. Works on any site, and reports whether WP Rollback is present |
| Capability | manage_options, plus update_plugins or update_themes |
| Safety | Read-only — touches nothing |
| Repeatable | Idempotent |
| Ships in | AcrossAI Abilities Manager 0.0.45 and later |
How it works
Takes no input. It returns the asset types that can be re-versioned, where release history comes from, whether WordPress core is covered, and a plain list of limits.
The important thing it tells you is what is not possible. WordPress core is never covered here — that is a different pair of abilities. And release history comes from WordPress.org, so a premium or privately-hosted plugin has none there: it can only be restored to a version this site already holds a local archive of, and local archives are the one thing WP Rollback adds.
Input
None. Call it with an empty object.
What comes back
| Name | Type | What it is |
|---|---|---|
wp_rollback_active | boolean | Whether the WP Rollback plugin is loaded. Version moves do not need it; its local archive does. |
host_plugin | object | WP Rollback’s name, slug, plugin file, active state and directory link. |
supported_types | array | plugin and theme. |
covers_core | boolean | Always false, and stated rather than implied — WordPress core needs core/rollback-wp-core or the core pinning abilities. |
version_source | string | Where release history comes from: wordpress.org. |
limits | array | The constraints in plain sentences, ready to show a human. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what this site can do. |
Example
Ask your assistant:
Can I roll a plugin back on this site?
It resolves to one call with no parameters:
{
"ability": "versions/get-rollback-status",
"parameters": {}
}Worth knowing
- Version moves do not require WP Rollback. They go through WordPress core’s own upgrader, which has backed the previous copy up and restored it on failure since WordPress 6.3.
- What WP Rollback adds is its local archive of versions it has installed before — the only route to an earlier version of a plugin WordPress.org does not host.
- WordPress core is not covered. That is deliberate and reported, so an assistant asked to downgrade core is sent to the right abilities rather than failing here.
- A successful rollback means files were replaced, not verified. For a WordPress.org plugin,
plugins/verify-plugin-checksumscan confirm them afterwards.
Related abilities
- List Asset Versions — every release WordPress.org published for one asset
- Check Asset Rollback — pre-flight a specific move
- Get Core Pin — the same question for WordPress core
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category