plugins/verify-plugin-checksums can tell you that a plugin’s files no longer match what WordPress.org published for its version — a half-finished update, a truncated upload, an edit somebody made directly on the server. Until now, nothing could put them back.
plugins/reinstall-plugin is that repair. It re-downloads and re-applies the official package for the version the plugin is already on, so the version does not change — which makes it safe in a way a rollback is not. Your settings and database content are untouched.
At a glance
| Ability | plugins/reinstall-plugin |
| Toolset | Updates — toolset/updates |
| Group | Version Targeting › Reinstall |
| Requires | Nothing. The plugin must be published on WordPress.org |
| Capability | manage_options and update_plugins |
| Safety | Destructive — replaces files on disk. The version does not change |
| Repeatable | Idempotent — safe to re-run |
| Honours | DISALLOW_FILE_MODS |
| Ships in | AcrossAI Abilities Manager 0.0.45 and later |
No confirmation flag, and why
This ability takes no confirm. That matches core/reinstall-wp-core, which overwrites the whole of WordPress without one, and the reasoning is the same: the operation returns a plugin to its own current version rather than moving it anywhere. Requiring confirmation here would be stricter than the core equivalent for a strictly smaller operation.
The rollback abilities, which do change version, require confirmation.
How it works
It drives WordPress core’s own Plugin_Upgrader. 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 — so a failed reinstall leaves the plugin as it was rather than deleted.
The swap happens behind maintenance mode, so visitors never hit a half-written plugin, and an active plugin is reactivated exactly as it was found — an overwrite drops a plugin out of the active list as a side effect nobody asked for.
The installed version has to be one WordPress.org actually published. A site running a nightly, a patched build, or a version newer than the directory knows gets version_not_published — rather than a quiet downgrade to the nearest release dressed up as a repair.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
plugin | string | Yes | Folder name, plugin file, or display name. |
What comes back
| Name | Type | What it is |
|---|---|---|
reinstalled | boolean | Whether the package was applied. |
version | string | The version re-applied — the same one that was installed. |
plugin / plugin_name | string | The plugin as resolved, so you can confirm the right one was matched. |
was_active | boolean | Whether it was active before the reinstall, and therefore reactivated after. |
error_code | string | version_not_published, not_on_wordpress_org, reinstall_failed and similar. |
blocked_reason | string | Present when DISALLOW_FILE_MODS stopped it. |
Example
Ask your assistant:
The checksum check says Akismet has modified files — fix it.
{
"ability": "plugins/reinstall-plugin",
"parameters": {
"plugin": "akismet"
}
}Then verify it worked by running the checksum check again.
Worth knowing
- Deliberate edits inside the plugin’s folder are overwritten. That is what this ability is for — but if somebody customised a plugin in place, this undoes it.
- Settings and content live in the database and survive untouched.
- A premium or privately-hosted plugin cannot be reinstalled this way — there is no official package to re-apply.
- Pair it with
plugins/verify-plugin-checksumson both sides: detect, repair, confirm.
Related abilities
- Roll Back Plugin — change the version instead of re-applying it
- Reinstall Theme — the theme equivalent
- Check Asset Rollback — what a version move would affect
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category