Rollback

Every gated write is snapshotted while it runs: Ability Gate records the exact database rows before and after the change. Roll back on the request screen puts those rows back.

The drift check#

Before rolling back, Ability Gate compares each row with the state the action left it in. If someone or something changed a row since (for example an editor updated the same post), that is drift. The screen lists the changed rows and refuses to roll back unless you tick Override changes made since. This stops a rollback from silently overwriting newer work.

Rollbacks are recorded too#

A rollback is recorded as a new request with its own snapshot, so you can undo a rollback in the same way.

What rollback cannot undo#

• External effects such as an email sent, an outgoing HTTP call (a webhook, a payment gateway capture or refund), an uploaded file, a scheduled cron event, or a plugin or theme being activated, deactivated or updated. These are listed under “External effects (not undone by a rollback)”. To roll back the database part, you must tick I understand external effects are not undone.
• Partial snapshots. Some writes cannot be recorded exactly: tables without a primary key, schema changes (CREATE, ALTER, DROP, TRUNCATE), tables without your site’s table prefix, statements Ability Gate cannot parse, or a single statement touching more than 5,000 rows. The request is then marked “The snapshot is partial”, and those writes cannot be undone.

This is why abilities whose names suggest an external effect (send, email, notify, refund, charge, pay, capture, install, activate, upgrade, upload, publish) score higher and are held for approval by default rather than only snapshotted.

Caches after a rollback#

After restoring rows, Ability Gate cleans the matching WordPress caches: posts, meta, options, terms, users and comments, and WooCommerce product and order caches when WooCommerce is active. For other plugin tables it flushes the object cache when a persistent object cache is in use.