Revisions & Review
Chinaski keeps editorial history in three layers: autosaved drafts for the person typing, full snapshots for every saved version of an item, and an approval workflow that moves drafts through review. This page explains each layer and the “return for revision” cycle that closes the loop.
Quick answers
- What happens when I save? A full snapshot of the page, post, or document is captured before your change is written; the history is always at least one step behind your current edit.
- While I’m still typing? Your in-progress edit autosaves as a per-user draft, kept separately from the saved content and from other users’ drafts. Discarding it restores the saved version.
- What happens when a review is “returned”? The pending item goes back to the editor with an optional reason (recorded and emailed), and they can revise and resubmit.
Revisions
Every page, post, and document keeps its own revision trail:
- List view: newest first, with a field-level summary and a marker for which fields changed compared to the next revision. When the list exceeds the visible cap, the list says so.
- Diffs: compare any revision against the current live content, or two revisions against each other.
- Restore: pages and posts can be reverted to any selected revision; the restore itself is audited.
Each entity keeps a bounded history (the newest entries per item are kept; very old ones roll off), so history can’t grow without bound.
Drafts (autosave)
While you edit, your form autosaves as a draft that belongs to you: a draft key combines your user ID with the item, so two editors working on the same page each have their own autosave state and can’t overwrite each other’s unfinished button presses. You can discard your draft explicitly; it also never overrides the committed page automatically.
The review workflow
When Require approval (Settings → Workflow) is on, content from non-admins goes through a review cycle with four states:
Draft → Pending review → Approved (published) with Rejected as the loop-back state.
- Submit for review: an editor sends the item up; it moves to pending review (this is also what happens automatically when approval is on and an editor hits “publish”). The configured review-notification email gets a message with the title, the submitter’s name, and a direct link to review it.
- Approve: an admin approves: the item is immediately published and a build is dispatched; any leftover future scheduling date is cleared so the approved page actually goes live. The content creator gets an approval email if their account has an address, and the notification is audited.
- Reject (return for revision): an admin rejects with an optional reason. The item returns to its editor with a “rejected” status, the reason is recorded in the audit log, and the creator is emailed. They can then edit and submit again.
- A rejected or drafted item can be resubmitted any number of times; the re-approvals are all fresh decisions.
Two things to know in practice
- Email notifications need SMTP (Settings → Email) and are skipped entirely in air-gap mode; the workflow still works; delivery of the messages is what’s missing. Everything else (statuses, audit entries, flash confirmations) still functions.
- Approval publishes and rebuilds. Approving isn’t a rubber stamp on a previous draft state: it flips the item to published and triggers the site build for that content.
Revision reuse everywhere
Other content types reuse the same machinery: blocks and stacks keep their own revision trails with the same diff-and-restore interface, media items snapshot on each save, and every restore action is audited with the actor’s name.