Alles rückgängig

Jemand überschreibt den Teaser, zwei Tage später fällt es auf, und niemand weiß mehr, wie er vorher lautete. In RustyCMS ist jeder Write ein Snapshot: anlegen, ändern, Statuswechsel, Wiederherstellen — alles landet in der Historie des Eintrags, mit Zeitstempel und Urheber. Zurückdrehen ist ein Klick, kein Backup-Restore.

Jeder Write ein Snapshot

Die Aufzeichnung hängt am Schreibpfad, nicht an der Oberfläche. Ob der Eintrag aus der Admin-UI, per API-Key, über einen Import oder vom Scheduler geändert wurde, spielt keine Rolle. Versionen sind chronologisch sortierbar und tragen die Operation im Namen. Wie viele behalten werden, legt RUSTYCMS_VERSION_RETENTION fest — Default 50 pro Eintrag, 0 heißt unbegrenzt.

GET  /api/content/post/hello/history
GET  /api/content/post/hello/history/20260416T142200123-update
POST /api/content/post/hello/history/20260416T142200123-update/restore

Diff statt Raten

Im History-Panel des Editors wählst du zwei Versionen per Checkbox und bekommst einen Feld-für-Feld-Vergleich mit rot/grün markierten Änderungen. Jede Version lässt sich als Ganzes ansehen, bevor du sie zurückholst.

Restore, das selbst rückgängig ist

Ein Restore schreibt den alten Stand über den aktuellen — und zeichnet sich dabei selbst als neue Version auf. Nichts geht durch das Zurückdrehen verloren, ein Restore lässt sich wieder rückgängig machen. Vorher wird der Snapshot gegen das aktuelle Schema geprüft: hat sich das Modell seit damals geändert, schlägt der Restore laut fehl statt kaputte Daten zu schreiben.

Ein Audit-Log über alles

Die Frage „Wer hat gestern was geändert?” braucht keinen Blick in einzelne Einträge. Der Audit-Log geht über alle Collections und filtert nach Actor, Collection, Operation und Zeitraum — in der Admin-UI und per API:

GET /api/audit-log?actor=alice&collection=post&operation=update
    &since=2026-04-01T00:00:00Z&until=2026-04-17T23:59:59Z

Automatische Übergänge erscheinen dort als Operation status mit dem Actor system:scheduler. So unterscheidest du auf einen Blick, ob ein Eintrag von Hand oder per Terminierung live ging.

Was nicht passiert

Gelöschte Einträge lassen sich nicht aus der Historie wiederbeleben — der Eintrag muss noch existieren. Es gibt keine Branches und keinen Freigabe-Workflow; die Historie ist ein Protokoll, keine Redaktionsschleife. Git-Autocommit ist davon unabhängig: Git ist Disaster-Recovery für den ganzen Content-Baum, die Historie ist die Per-Eintrag-Sicht über die API.