History, compare, and restore

You already published Maya's homepage hero. This page is what you open after that — compare snapshots, republish a previous version as the new active one, or restore any version into the draft.

What this page is for

You already published Maya's homepage hero from Publishing. The first snapshot is 1.0.0. This page is what you open after that — when you need to see what changed, put last Tuesday's layout back in front of visitors, or check an older snapshot out into the draft.

Two everyday jobs:

Roll the live hero back now. This morning's headline was wrong. Publish this version on 1.0.0 creates a new active snapshot whose contents match the old one. Visitors pick it up after cache refresh.
Edit from a known-good snapshot. Restore to draft loads that version into the composer. The live site does not move until you publish again.

Publish History

RuleCMS keeps an append-only history of every publish in this environment. Nothing is deleted when you ship a new version. Each publish adds a row to Publish History.

Open it from the Publish tab or from the active published widget (or shared collection) page. The table shows:

Version — semantic patch increment per widget (or shared collection) per environment. Not a project-wide number.
Tag Name — the optional label you set at publish time. Republished rows auto-tag as Republished from version ….
Last Published At — when that snapshot was created.
View — a read-only archive of that exact snapshot, including preview and configuration.

The top row is always the currently active published version — what live consumers receive today. Older rows are historical snapshots you can inspect, compare, republish, or restore.

The version detail page shows an archive warning: you are viewing a snapshot, not necessarily what is live.

Compare versions

Compare is a side-by-side diff. Switch between Visual, JSON, and CSS Settings. JSON can show Raw or Diff.

You can start a compare from two places:

The Publish tab — Compare versions diffs the draft you are editing against the active published snapshot.
Publish History — Compare to previous on a row diffs that snapshot against the version published just before it.

Use compare before a republish, or after an incident, to see which components, copy, collection references, and catalog entries changed. The CSS Settings view is the same read-only catalog as the View pages, side by side.

CSS Settings on a published version

The active published widget page — and each historic version — has a CSS Settings tab. It is a read-only view of every catalog that shipped with that snapshot. Edit the draft widget to change it, then publish again.

Syncing later project updates onto the draft does not rewrite any published row. Those catalogs stay frozen on the version that carried them.

Republish a previous version

Publish this version copies a historical snapshot forward and makes that copy the new active published version. History stays intact. You are not deleting rows. You are fast-forwarding from an old snapshot.

If the active version is 1.0.7 and you republish 1.0.2, the new active version is 1.0.8 with 1.0.2's content. Version 1.0.2 stays 1.0.2. The new row auto-tags as Republished from version 1.0.2.

Republish does not change the composer draft.

Shared versus embedded on republish

Collection type	What republish does
Shared	References only. The widget snapshot points at the shared collection's current published content. Republish does not create a new shared collection version. If that card was updated since 1.0.2 was live, the republished hero shows the old widget layout with today's shared content.
Embedded	Copied again. Every embedded collection in that historical snapshot is recreated for the new publish event. The spring-sale price on the sale hero comes back as it shipped. Other widgets are unaffected.

Republish restores widget-owned structure — including embedded copies — while shared building blocks stay live-linked. That matches day-to-day publish: global content stays centralized; page-specific sections stay page-specific. The model itself is Collections.

How to republish

You can start from two places:

Publish History — on any row except the newest (active) one, click Publish this version.
Version detail page — open View on a historical row, then click Publish this version in the header.

The confirmation is titled Publish Version …. It names the next version number, and it says shared collections are not changed while embedded collections are copied. Confirm with Publish or Cancel.

The same Publish to Staging or Publish to Production permission that allows a normal publish controls republish. No separate grant is required.

When republish is not available

Already active — the top history row cannot republish onto itself.
Missing permission — teammates who can view history but not publish do not see the action.
Older snapshots — a version published before republish was supported shows as disabled, with a tooltip that it cannot be republished.

Restore a version to your draft

Republish changes what is live. Restore to draft changes what you are editing: it loads any published snapshot back into the composer draft. From there you edit and publish as usual.

Unlike republish, restore is available for every row in Publish History — including the currently active one. That is the fastest way to throw away unpublished draft experiments and get the draft back in sync with what is live.

When you reach for it

Start over from what is live. The draft has half-finished changes you no longer want. Restore the active version and the draft matches Production again.
Branch from an older release. Yesterday's layout is closer to the new campaign than today's. Restore it, adapt it, and publish the next version.
Investigate before rolling back. Restore a suspect version, fix it in the composer, and publish a corrected forward version — instead of republishing the old snapshot as-is.

What restore does

Replaces your draft with the selected snapshot. Unpublished draft changes are discarded.
Does not touch published content. The active version, history, and everything live apps load stay as they are.
Does not publish anything. After a restore, that content lives only in the draft. Ship it with Publish Now or Publish New Version when you are ready.

Shared versus embedded on restore

Collection type	What restore does
Shared	Re-linked, never copied. The restored draft references the same shared collection your team already edits. Its draft and published content are not changed. If a shared collection that version named has since been deleted, the restore stops with a clear message before anything is written.
Embedded	Copied into the draft. Each embedded collection in the snapshot becomes a fresh, fully editable draft collection belonging to this widget — nested copies included. The sale price you see is exactly what shipped in that version.

Embedded collections that were in the draft before the restore are no longer referenced by the widget. They are not deleted, but they will not appear in the composer or be published going forward.

How to restore

You can start from two places:

Publish History — click Restore to draft on any row, including the newest (active) one.
Version detail page — open View on any row, then click Restore to draft in the header.

The confirmation is titled Restore Version … to Draft. It leads with the consequence: the current draft will be replaced, and unpublished changes will be lost. Confirm with Restore to Draft or Cancel. On success you get Open the widget (or the collection) to keep editing.

Restore is controlled by the same Widget Access (or Collection Access) needed to edit in the composer. Publish permission is not required, because nothing is published.

When restore is not available

Draft no longer exists — if the widget or shared collection the version was published from has been deleted, the restore stops with a clear message.
Missing permission — teammates without edit rights in that environment do not see the action.
Older snapshots — a version published before restore was supported shows as disabled.

Restore is not undoable from the UI. Published history is append-only, so you can always restore again from any version — including the one that was live before you started.

Republish, restore, or publish?

You want to…	Use	What changes
Put an older release back in front of visitors right now	Publish this version (republish)	Published state — a new active version is created; the draft is untouched
Edit an older release, or discard draft experiments, before shipping anything	Restore to draft	Draft only — published state is untouched until you publish
Ship the work currently in your draft	Publish Now / Publish New Version	Published state — a new active version is created from the draft

A rollback habit that works

Open Publish History for the affected widget in Production.
View the last known-good version. Use Compare to previous if you need to confirm what changed.
Publish this version. Note the new version number. History is preserved.
For the forward fix, Restore to draft from that known-good version so the draft starts from what is now live. Correct it in the composer, then publish when ready.

After the first publish, later publishes and republishes invalidate cached copies of that widget for every enabled token in the environment, so consumers do not keep serving the stale snapshot. The first publish — version 1.0.0 — has nothing cached yet, so that invalidation is skipped.

Shared collections have the same history, compare, republish, and restore actions. Embedded collections do not — they have no isolated publish, so they have no isolated history.