How to Revert CMS Pages & Blocks in Magento 2

Made a mistake editing a CMS page or block in Magento? There's no undo button. This guide covers every option for reverting content changes — from manual workarounds to tools that track revisions automatically.

The problem: Magento has no undo for CMS content

When you edit a CMS page or CMS block in Magento 2 and hit save, the previous version is gone. There's no revision history, no undo button, and no way to see what the content looked like before you changed it.

This is a significant limitation for any store where CMS content matters — which is most stores. Landing pages, promotional banners, homepage blocks, and informational pages are all managed through the CMS, and a single bad edit can break layouts, remove critical content, or publish incorrect information.

Unlike platforms like WordPress, which has built-in revision tracking for every post and page, Magento's CMS editor simply overwrites the previous content on every save.

What happens when you save a CMS page in Magento

When you click save on a CMS page or block, Magento writes the new values directly to the cms_page or cms_block database tables. The previous values are not stored anywhere — they're simply replaced.

This means:

• There is no revision history to browse or compare
• There is no way to see who changed what or when
• If you didn't copy the old content before editing, it's gone
• The only record might be in your database backups — if you have them

Option 1: Ctrl+Z (before saving)

The simplest option — but only works if you haven't saved yet. If you're still in the editor and realise you've made a mistake, you can undo your changes with Ctrl+Z (or Cmd+Z on Mac).

This works for:

• Text content in the WYSIWYG editor
• Page Builder changes (though it can be unreliable with complex layouts)

Once you've hit save, however, Ctrl+Z won't help. The old content has been overwritten in the database.

Option 2: Restore from a database backup

If you have regular database backups (and you should), you can extract the old CMS content from a backup and manually restore it.

Steps to restore CMS content from a backup

1. Import your database backup into a temporary database
2. Find the page or block you need to restore:

   -- For CMS pages
   SELECT page_id, identifier, title, content
   FROM cms_page
   WHERE identifier = 'your-page-identifier';
   
   -- For CMS blocks
   SELECT block_id, identifier, title, content
   FROM cms_block
   WHERE identifier = 'your-block-identifier';

3. Copy the old content values
4. Update the live database or paste the content back into the Magento admin editor

Limitations of this approach

• Backups may be hours or days old — any changes made between the backup and your mistake are also lost
• Requires database access — not something every team member can or should do
• Time-consuming — importing a full database backup, finding the right content, and restoring it takes significant effort
• Risk of overwriting other changes — restoring an entire table from backup could undo other legitimate changes

Option 3: Copy content before editing (manual versioning)

Some teams adopt a manual workflow: before editing a CMS page or block, copy the existing content to a document, spreadsheet, or text file. If something goes wrong, you can paste it back.

This works, but it relies on discipline. The moment someone forgets to copy the content before editing, the safety net is gone. It also doesn't help if someone else on your team makes an edit you weren't expecting.

Option 4: Use Git to track CMS content (developer approach)

Some development teams export CMS content to files and track them in version control. Tools and approaches include:

• Custom data patches — write Magento data patches that set CMS content, tracked in Git
• CMS content sync modules — third-party modules that export CMS content to files
• Manual export scripts — custom scripts that dump CMS content to JSON or XML

While this gives you full version history, it only works for content that has been committed to Git. Ad-hoc admin edits — the kind marketing teams make every day — won't be tracked unless someone remembers to export and commit after every change.

Option 5: Adobe Commerce Content Staging

Adobe Commerce (the paid enterprise edition of Magento) includes a Content Staging feature that lets you schedule content changes. While it provides some version management, it has significant limitations:

• Requires an Adobe Commerce licence — not available on Magento Open Source
• Designed for scheduling, not revision tracking — the focus is on scheduling future content updates, not maintaining a history of past changes
• Adds database complexity — duplicates rows in content tables for every scheduled update, which can bloat your database over time
• No easy rollback to arbitrary past states — you can't browse a timeline of how a page looked at different points and revert to one

Option 6: Automatic revision tracking with MageDrop

MageDrop solves this problem by automatically capturing a revision every time a CMS page or block is saved in Magento. No extra steps, no manual copying — it just works in the background.

How it works

1. Install the MageDrop companion module in your Magento store
2. Edit CMS content as normal — every time you save a page or block, the module automatically sends a snapshot of the content to MageDrop
3. Browse revision history in the MageDrop dashboard — see every version of every page and block, who made the change, and when
4. Rollback with one click — select any previous revision and push it back to Magento instantly

What gets captured

Every scalar field on the entity is captured in the revision: title, content, meta title, meta description, status, identifier, and more. MageDrop stores the complete state of the entity at the time of each save.

Comparing revisions

In the MageDrop dashboard, you can view any revision and see a field-by-field diff against the previous version. Changed fields are highlighted, and you can click into any field to see the full before-and-after comparison — useful for spotting exactly what changed in long Page Builder content.

Rolling back

When you click "Rollback" on a revision, MageDrop:

1. Snapshots the current live state first (so the rollback itself is reversible)
2. Pushes the selected revision's data back to Magento via the REST API
3. Logs the rollback in the activity feed

The entity is updated immediately on the live store. Because MageDrop captures the current state before rolling back, you can always undo a rollback by reverting to the previous revision.

Who changed what

Every revision records the Magento admin username of the person who made the change. This gives you a full audit trail — useful for teams where multiple people edit CMS content.

Comparing the options

Summary

Magento doesn't track CMS content history out of the box, which means reverting a bad edit can range from inconvenient to impossible depending on your setup. The best approach depends on your team:

• Solo developer making a quick fix? Ctrl+Z before saving is usually enough.
• Team with database access and regular backups? Restoring from a backup works but is slow and error-prone.
• Agency or team with multiple editors? Automatic revision tracking with MageDrop gives you a complete safety net — every save is captured, every change is attributable, and any version can be restored with a single click.