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 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.

That's a real limitation for any store where CMS content matters, which is most of them. Landing pages, promotional banners, homepage blocks and information pages are all managed in the CMS, and a single bad edit can break a layout, remove important content or publish the wrong information.

Unlike WordPress, which keeps revisions of 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 save a CMS page or block, Magento writes the new values directly to the cms_page or cms_block table. The previous values aren't stored anywhere; they're replaced.

This means:

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

Option 1: Ctrl+Z (before saving)

The simplest option, but it only works if you haven't saved yet. If you're still in the editor and spot a mistake, undo it with Ctrl+Z (or Cmd+Z on a Mac).

This works for:

• Text in the WYSIWYG editor.
• Page Builder changes, although it can be unreliable with complex layouts.

Once you've saved, Ctrl+Z can'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 pull the old CMS content out of a backup and restore it by hand.

Steps to restore CMS content from a backup

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

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

3. Copy the old values.
4. Paste the content back into the Magento admin editor, or update the live database.

Limitations of this approach

• Backups may be hours or days old. Changes made between the backup and your mistake are lost too.
• It needs database access, which not everyone on the team can or should have.
• It's slow. Importing a full backup, finding the right content and restoring it takes real effort.
• It can overwrite other changes. Restoring a whole table from a backup could undo legitimate edits.

Option 3: Copy content before editing (manual versioning)

Some teams copy the existing content to a document, spreadsheet or text file before every edit, so they can paste it back if something goes wrong.

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

Option 4: Track CMS content in Git (the developer approach)

Some development teams export CMS content to files and track them in version control, using:

• Data patches: Magento data patches that set CMS content, tracked in Git.
• CMS content sync modules: third-party modules that export CMS content to files.
• Export scripts: custom scripts that dump CMS content to JSON or XML.

This gives you full history, but only for content that has been committed. Ad-hoc admin edits, the kind marketing teams make every day, aren't tracked unless someone remembers to export and commit after every change.

Option 5: Adobe Commerce Content Staging

Adobe Commerce (the paid edition of Magento) includes Content Staging for scheduling content changes. It offers some version management, with significant limits:

• It needs an Adobe Commerce licence and isn't available on Magento Open Source.
• It's designed for scheduling, not history. The focus is on future updates, not on keeping a record of past changes.
• It adds database complexity, duplicating rows in content tables for every scheduled update, which can bloat the database over time.
• There's no easy way back to an arbitrary point. You can't browse a timeline of how a page looked and restore one version.

Option 6: Automatic revisions with MageDrop

MageDrop captures a revision automatically every time a CMS page or block is saved in Magento, and every time a category or product is saved in the admin. No extra steps and no copying: it works in the background.

How it works

1. Install the MageDrop companion module on your Magento store.
2. Edit content as usual. Every time you save a page or block, the module sends a snapshot to MageDrop.
3. Browse the history in the MageDrop dashboard: every version of every page and block, who changed it and when.
4. Restore with one click. Pick any earlier revision and push it back to Magento straight away.

What gets captured

Every content field on the page or block is captured in each revision: title, content, meta title, meta description, status and more, together with the store view it was saved at.

Comparing revisions

In the dashboard, you can open any revision and see a field-by-field diff against the previous one. Changed fields are marked, and you can open any field to compare the before and after in full, which is handy for spotting exactly what changed in long Page Builder content.

Restoring

When you click Restore on a revision, MageDrop:

1. Snapshots the current live state first, so the restore itself can be undone.
2. Pushes the content fields that differ back to Magento through the MageDrop module.
3. Logs the restore in the store's activity log.

The live store is updated immediately. Because the current state is captured before every restore, you can always undo one by restoring the snapshot taken just before it. Deleted pages and blocks can even be recreated from their last revision.

Who changed what

Every revision records the Magento admin user who made the change, giving you a full audit trail, which is especially useful when several people edit CMS content.

Comparing the options

Summary

Magento doesn't keep CMS history out of the box, so reverting a bad edit ranges 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 it's slow and error-prone.
• Agency or team with several editors? Automatic revisions with MageDrop give you a complete safety net: every save is captured, every change is attributable, and any version can be restored with one click.