Change History and rollback

EMCP records supported mutations in a shared History ledger. Coverage is operation-specific: a recorded entry can be informational, reversible, or unavailable for automatic undo. Builder-native revisions and adapter recovery snapshots are separate mechanisms.

Version 3.17.0 adds creation undo for Elementor pages and uploads, records page settings and CSS, and strengthens rollback checks. It does not reconstruct changes omitted by older versions or make every builder operation reversible.

History tools

All three require manage_options and are enabled by default.

Tool	Inputs	Purpose
emcp-tools/list-changes	Optional domain, rolled_back, reversible, limit	List recent recorded changes without heavy snapshot payloads
emcp-tools/get-change	id	Read one entry and its recovery details
emcp-tools/rollback-change	id, optional force	Attempt verified restoration for an eligible entry

Read the live schema and entry before undoing. Listings explain why an entry is unavailable for automatic rollback; retained snapshots can still support inspection.

What changes in 3.17.0

• Elementor page creation: create-page records one creation event including initial content and returns change_id. Undo removes the created page rather than reverting only its initial content.
• Uploaded media: upload-media returns a creation change ID. Undo checks for later attachment or file changes, removes the attachment and verifies deletion of recorded WordPress-managed files, including generated sizes on Windows.
• Page settings and CSS: exact prior metadata is retained, including absent values and escaped CSS. Identical CSS saves do not add duplicate records. Restoration invalidates Elementor caches.
• Conflict checks: guards cover the state changed by the operation, including metadata, taxonomies, users and ACF. Unrelated post-field edits are preserved.
• Verified restoration: failed writes, missing file backups, occupied IDs and ledger persistence failures do not report ordinary rollback success.

Conflicts and force

A later edit can prevent rollback when the current target differs from the recorded after-state. Inspect that difference before deciding whether to proceed. force is not a bypass for incomplete snapshots or missing recovery data.

Database changes recorded before 3.20.0 (they matched rows by the WHERE columns, not a key), older post snapshots without complete guards, and generic attachment-deletion records without file backups refuse automatic undo even with force. A successful rollback requires a supported recovery contract and verification of the restored result.

Database changes (3.20.0)

Since 3.20.0 History can undo the database tools again: insert-row, update-rows and delete-rows, and All in One SEO post changes. Each write locks the rows it touches and History records every row by its primary key, with what it held before, in the same transaction as the write. If the record cannot be saved, the write is cancelled too.

• Undo puts the rows back by key: deleted rows return under their original ids, an inserted row is removed, and updated rows get their old values.
• If a row has changed since, the undo reports a conflict. Only Undo anyway (force: true) overwrites it. If putting a row back would clash with a unique key, the undo is cancelled and nothing changes.
• A write that would change more than 500 rows is refused with too_many_rows, and nothing is changed.
• Some writes still run but cannot be undone: a table without a primary key, a table that is not InnoDB, or an update that changes primary key values. The tool answer says so in undoable and not_undoable.

Database changes recorded by 3.17.0 to 3.19.x stay not undoable.

Term changes (3.20.0)

The term tools (create-term, update-term, delete-term) record every write, and each answer carries a change_id.

• Undo a create deletes the term again. It is refused while a menu links to the term.
• Undo an update puts back the name, slug, description, parent and the meta keys the update changed.
• Undo a delete brings the term back under its original id with its meta, its posts and the child terms WordPress moved up a level. Where WordPress gave a post the default category because it was left with none, undo takes that default category off again.
• An undo is refused with nothing written when the term’s parent is gone (linked_unavailable) or another term took its slug (slug_taken).
• The person undoing needs the taxonomy’s own term permissions, not only access to History.

The History screen

Open EMCP Tools → Safety → History (admin.php?page=emcp-tools-history). The header counts the recorded changes and how many were rolled back. The screen was rebuilt in 3.18.0 around sessions, undo and a difference view. The full screen guide is History.

Sessions

Changes are grouped into sessions, newest first. A session is one connected client’s MCP session, one AI Chat conversation, or, for older changes without a session, the changes one user and client made within 30 minutes. A change made in wp-admin (for example a redirect you edited) is its own group. Each session shows its first change, a client badge (such as ADMIN, WP-CLI, AI Chat or an OAuth app name), the number of changes and the time.

Inside a session each row shows an icon for the kind of change, its title, the target, the action (create, update or delete) and a relative time. Show more changes loads the rest of a large session, and Load older sessions at the end of the list loads the next page.

Undo a change or a whole session

• Undo on a row restores that one change. If the target changed since the change was recorded, the screen asks “This changed since …” and offers Undo anyway, which is the same as force: true on rollback-change. The same refusals apply: an entry without a complete recovery record cannot be undone, even anyway.
• Undo whole session (with a confirmation) undoes every change in the session, newest first, and stops at the first change that cannot be undone.
• Undone rows carry a Rolled back badge. The undo itself is also recorded, so History shows what happened.
• The bin icon (Delete from History) removes one entry from the list without changing the site.

View the difference

Choose the eye button on a row to open View difference: a line diff of the saved before-state against what is there now. Elementor data and options show as formatted JSON, post fields and meta as text sections, and files as text. Some changes have no preview, and the panel then says why, for example “This kind of change has no preview.”, “The content is larger than 256 KB.” or “This file is binary.”.

Filters

Use Search changes, the kind tabs All / Content / Design / Settings, the Client menu (All clients, or one client seen in the log) and the Time range menu (All time, Last 24 hours, Last 7 days, Last 14 days, Last 30 days). Sessions with no matching change are hidden.

Retention and clearing

The Retention menu in the header keeps changes for 30, 90, 180 or 365 days (default 90); older entries are pruned daily, and an expired entry can no longer be undone. Clear history deletes every entry and its undo record after you type CLEAR to confirm. This cannot be undone. History is not a substitute for a site backup.

Banners

A banner at the top of History appears when something needs attention:

• “Some changes are missing from History”: a change could not be recorded (for example under heavy contention). Dismiss it once you have checked.
• “Reconnect your AI client”: a client still runs the code from before 3.18.0, so its changes are not recorded. Restart the client or reload its MCP server.
• “History is using its compatibility store” and “History could not finish its upgrade”: the 3.18.0 move of History to its own database table has not completed. These cannot be dismissed and clear themselves once the upgrade finishes.

The Dashboard’s Recent changes card shows the five newest changes with the same Undo button and a View history link.

Attachment deletion and backups

The dedicated media deletion workflow can preserve original files, generated sizes, post data and metadata in a managed backup before permanent deletion. Recovery depends on that complete backup and an available original ID. WordPress media Trash, when used, follows its own trash/untrash lifecycle.

A generic attachment-deletion snapshot does not necessarily contain files. Inspect the entry rather than assuming every deleted attachment can be restored. Missing backups or occupied IDs prevent restoration.

Builder recovery and Content Mirror

Use each builder reference for native revision, staging and snapshot tools. A native revision may cover page content without covering global settings or template conditions. For example, Oxygen uses additional snapshots for template settings and global design documents.

Content Mirror provides file-based exports for longer-lived, diffable history. The ledger is an in-database record kept for the retention period you choose. Full site recovery still belongs to your backup workflow.