Skip to main content

Site Archive

Site Archive captures point-in-time HTML snapshots of published assets. When an asset (or any asset it references or embeds) publishes, the plugin queues a snapshot, renders the asset deterministically, stores the resulting HTML, captures the underlying field values and a diff against the previous snapshot, and records the result as a searchable archive entry.

The plugin ships with sensible defaults and a CMS UI out of the box. Projects extend or override behavior through small extension points and settings-based configuration, with no required project glue beyond marking which asset types should be archived.

Key capabilities​

  • Automatic, deterministic HTML snapshots on publish, including cascading snapshots of assets that reference the published asset.
  • A field-level diff against the previous snapshot, so an editor can see exactly what changed between two archive entries.
  • A searchable archive of every snapshot, with an Archive History widget on each archived asset.
  • Automatic retries when a snapshot fails to render, so a transient failure does not permanently cost an asset its snapshot.
  • Extension points for adding custom HTML to snapshots, excluding specific asset types from cascading, and customizing the render request.
  • Configurable storage, path prefixes, URLs, and permissions so a project can fit the archive into its existing storage and navigation scheme.

How it works​

Publishing an asset triggers a chain of background work rather than an inline render. A save that is a publish and is not excluded from cascading queues a relationship-tracking row for every asset that references the published asset. A task then refreshes each of those assets' reference indexes and, if the asset actually changed, queues an archive-creation row for it. A second task drains the archive-creation queue on a configurable schedule: it renders each asset, writes the HTML to storage, captures the field diff, and saves the resulting archive entry. A render that fails is retried on a later run of the same task before it is recorded as an error, so a transient failure does not permanently cost the asset its snapshot.

Use cases​

A regulated organization needs to prove what a page said on a given date. An editor or a compliance reviewer opens the asset's Archive History widget, finds the entry closest to the date in question, and opens the stored HTML, which renders exactly as it did at snapshot time, independent of any later template or asset change.

Editorial audit trail​

An editorial team wants to see how an article evolved across revisions. A reviewer opens the archive search UI, filters to the article, and steps through its entries in order, using the field diff on each entry to see exactly which fields changed since the previous snapshot, without having to compare full HTML by hand.

Backfilling a newly enabled archive​

A project enables Site Archive on a site that already has years of published assets. Because archive entries are only queued on publish, existing assets have no snapshots yet. An administrator runs the backfill task from the Code tool to queue archive-creation rows for existing assets, then temporarily tightens the archive-creation task's cron schedule so the queue drains in a reasonable time.

Excluding shared, low-value assets from cascading​

A project's articles all reference a global navigation asset that changes often but is not editorially meaningful on its own. A developer marks the navigation asset's class as excluded from the archive cascade so that routine navigation edits do not trigger a new snapshot of every article that references it.

Who this documentation is for​

  • CMS editorial—for editors and administrators who enable the feature and review archive entries in the CMS.
  • Technical reference—for developers who add the plugin to a project, mark asset types as archivable, and extend its behavior.

Was this page helpful?

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.