History & Snapshots

Every time you click Publish in the Builder, the draft is serialised, hashed, and stored as an immutable row in the dd_quiz_snapshots table. The History tab in the Builder lists every snapshot for the quiz; restore any of them back to draft, tweak, republish.

The undo is the workflow.

[SCREENSHOT: The History tab showing a list of snapshots, newest first.]

What’s in a snapshot

Each snapshot row carries:

• A SHA-256 hash of the serialised payload, so you can detect identical republishes.
• The publish note (what you typed into the publish modal).
• The author (the WordPress user who clicked Publish).
• The timestamp of the publish.
• The full quiz tree — variants, questions, answers, upvote mappings, routing graphs — serialised into a single column.

Snapshots are append-only. Nothing in the Builder edits or replaces a historical snapshot row; the only mutation on the table is insert on publish.

Browsing snapshots

Open the History tab on any quiz. Snapshots appear newest first, with the publish note, author, and date. The currently published snapshot is marked.

Click any snapshot to expand its detail view:

• The publish note.
• The author and timestamp.
• A summary of changes vs the previous snapshot (questions added, answers changed, upvote weights updated).
• A Restore button.
• (Optional) A Rename action that updates the publish note in-place — useful for adding context to a snapshot you’ve come to recognise as significant.

Restoring a snapshot

Restore copies the snapshot’s payload back into the draft tables, overwriting your current draft. The flow:

1. Click Restore on the snapshot you want.
2. Confirm in the modal. Your current draft will be replaced.
3. The Builder calls POST /quizzes/{id}/snapshots/{sid}/restore.
4. The snapshot is unpacked into the draft tables; the dino_discover_draft_replaced action fires.
5. The Edit tab refreshes with the restored content.

Restore creates a draft, not a publish

Restoring does not automatically republish. You’re back in draft mode, with the restored content. Click Publish when you’ve reviewed it.

The previous draft state is gone — but it was almost certainly captured as a snapshot anyway (you publish before you restore, or your auto-save was already in the draft tables since the last publish). If you want to be extra-safe, publish your current draft as a snapshot before restoring; that gives you a clean undo point.

What gets logged

Every publish writes a snapshot row. Every restore fires the dino_discover_draft_replaced action — you can subscribe with your own listener if you want to log restores externally; the plugin ships no default listener for this action today.

There’s no “delete snapshot” UI in 0.1.0 — snapshots are kept indefinitely. If your dd_quiz_snapshots table gets large over the years, a separate housekeeping path can prune old snapshots; the default behaviour is to keep them all.

Snapshot retention vs event retention

The two are different:

Table	Default retention
dd_quiz_snapshots	Indefinite — snapshots are append-only and not auto-pruned.
dd_events	90 days by default, configurable in Settings → Event retention.

So your publish history stays as far back as the plugin has been installed; your raw storefront event log is bounded. The pre-rolled aggregates that power the dashboard are kept longer than raw events.

Cross-quiz comparison

There’s no built-in diff between snapshots across different quizzes — each quiz’s history is independent. If you want to compare two quizzes, the path is:

• Export both as JSON via GET /quizzes/{id}/export.
• Diff the JSON locally.

What’s next

• Draft & Publish — the publish flow that creates these snapshots.
• Drafts, Publishing & Snapshots — the architectural model.
• Settings — event retention and related defaults.
• Hook Reference — quiz_published and draft_replaced actions.