EmDash hält die veröffentlichte Version eines Eintrags getrennt von unveröffentlichten Änderungen. Das Admin-Panel, die REST-API, die Befehlszeilenschnittstelle (CLI) und die Model-Context-Protocol-(MCP-)Tools verwenden dieselben Lebenszyklusregeln.
Ein Eintrag kann draft, scheduled oder published sein. Ein veröffentlichter Eintrag kann auch einen Entwurf und einen
zukünftigen Zeitplan haben: Besucher erhalten weiterhin die Live-Revision, bis der geplante Entwurf
veröffentlicht wird. Der Papierkorb ist vom Status getrennt. Ein gelöschter Eintrag behält seine Lebenszyklus-Metadaten, wird aber
von gewöhnlichen Inhaltslesevorgängen ausgeschlossen.
Zustandsübergänge
Die folgende Tabelle ist der kanonische Vertrag für Inhaltszustand, Revisionszeiger und Veröffentlichungszeitstempel. „Keine Änderung“ bedeutet, dass die Operation den gespeicherten Wert beibehält.
| Aktion | Ausgangszustand | Ergebnis | Revisionseffekt | publishedAt | scheduledAt | Wiederholter Aufruf |
|---|---|---|---|---|---|---|
| Änderungen speichern | Jeder aktive Eintrag | Status ändert sich nicht | Bei einer revisionsfähigen Collection ersetzt die Entwurfsrevision, während die Live-Revision öffentlich bleibt | Keine Änderung | Keine Änderung | Ein geliefertes _rev lehnt einen veralteten Speichervorgang ab; ohne es ist der REST-Schreibvorgang bedingungslos |
| Veröffentlichen | Entwurf, geplant oder veröffentlicht | Veröffentlicht | Befördert die Entwurfsrevision zu live und löscht den Entwurfszeiger | Beim ersten Veröffentlichen gesetzt; bei späteren Veröffentlichungen beibehalten, sofern ein autorisierter Aufrufer ihn nicht überschreibt | Gelöscht | Behält den Live-Inhalt und die Veröffentlichungszeit bei, gibt aber ein neues _rev zurück |
| Bei Fälligkeit veröffentlichen | Geplant, oder veröffentlicht mit geplantem Entwurf | Veröffentlicht | Wie Veröffentlichen | Verwendet die geplante Zeit beim ersten Veröffentlichen; behält den bestehenden Wert beim Veröffentlichen eines neuen Entwurfs über Live-Inhalt | Gelöscht | Ein späterer Scheduler-Durchlauf überspringt einen Eintrag, dessen Zeitplan bereits gelöscht wurde |
| Veröffentlichung zurücknehmen | Jeder aktive Eintrag | Entwurf | Löscht den Live-Zeiger; behält den bestehenden Entwurf oder erstellt einen aus der Live-Revision | Beibehalten | Gelöscht | Ein Eintrag, der bereits ein einfacher Entwurf ist, ändert sich nicht |
| Planen | Entwurf, geplant oder veröffentlicht | Ein Entwurf wird geplant; ein veröffentlichter Eintrag bleibt veröffentlicht | Keine Änderung | Keine Änderung | Auf die angeforderte zukünftige Zeit gesetzt | Ersetzt den bestehenden Zeitplan und gibt ein neues _rev zurück |
| Planung aufheben | Geplant, oder veröffentlicht mit Zeitplan | Ein geplanter Eintrag wird Entwurf; ein veröffentlichter Eintrag bleibt veröffentlicht | Keine Änderung | Keine Änderung | Gelöscht | Ein Eintrag ohne Zeitplan ändert sich nicht |
| Entwurf verwerfen | Jeder aktive Eintrag | Status ändert sich nicht | Löscht den Entwurfszeiger; die Live-Revision bleibt unverändert | Keine Änderung | Keine Änderung | Ein Eintrag ohne Entwurf ändert sich nicht |
| In den Papierkorb verschieben | Jeder aktive Eintrag | Im Papierkorb und aus gewöhnlichen Lesevorgängen entfernt | Beibehalten | Beibehalten | Beibehalten | Eine Anfrage für einen bereits im Papierkorb befindlichen Eintrag gibt nicht gefunden zurück |
| Aus dem Papierkorb wiederherstellen | Im Papierkorb | Entwurf | Löscht den Live-Zeiger; behält jeden Entwurfszeiger | Beibehalten | Gelöscht | Erfordert einen Eintrag, der noch im Papierkorb ist |
| Dauerhaft löschen | Im Papierkorb | Entfernt | Entfernt den Eintrag und seine Revisionen | Entfernt | Entfernt | Kann nicht wiederholt oder rückgängig gemacht werden |
| Eine Revision wiederherstellen | Jeder aktive Eintrag | Status ändert sich nicht | Bei einer revisionsfähigen Collection ersetzt den Entwurf durch eine Kopie der ausgewählten Revision; die Live-Revision bleibt unverändert | Keine Änderung | Keine Änderung | Erstellt eine neue Revision und gibt ein neues _rev zurück |
Bei einer Collection ohne Revisionsunterstützung verwenden Speichern und Veröffentlichen die Inhaltszeile statt Live- und Entwurfszeigern. Das Wiederherstellen einer Revision schreibt die ausgewählten Feldwerte direkt in diese Zeile.
Das Wiederherstellen einer Revision bei einer revisionsfähigen Collection veröffentlicht sie nicht. Veröffentlichen Sie den Eintrag nach Prüfung des wiederhergestellten Entwurfs.
Berechtigungen und Schreibschutz
Berechtigungen hängen vom Besitz ab. Ein Author kann auf einen eigenen Eintrag einwirken; ein Editor kann dieselbe Aktion auf jedem Eintrag ausführen. Dauerhaftes Löschen erfordert einen Admin.
Das Setzen von publishedAt beim Veröffentlichen erfordert content:publish_any, auch wenn der Aufrufer den
Eintrag besitzt.
Die REST-API akzeptiert _rev als optionale optimistische-Concurrency-Voraussetzung, wo angegeben. MCP-Tools
erfordern es für dieselben Operationen, sodass ein Agent den Eintrag vor dem Ändern lesen muss. Ein veraltetes Token
gibt CONFLICT zurück. Admin- und REST-Schreibvorgänge, die durch eine Eintragssperre geschützt sind, geben ENTRY_LOCKED zurück, sofern eine
autorisierte Anfrage die unterstützte Sperrüberschreibung nicht verwendet. MCP-Schreibvorgänge nehmen nicht an Eintragssperren teil.
| Aktion | Berechtigung | REST _rev | MCP _rev | Admin- und REST-Sperre | Hooks |
|---|---|---|---|---|---|
| Änderungen speichern | content:edit_own oder content:edit_any | Optional | Erforderlich | Erzwungen | content:beforeSave, content:afterSave |
| Veröffentlichen | content:publish_own oder content:publish_any | Optional | Erforderlich | Erzwungen | content:beforePublish, content:afterPublish |
| Veröffentlichung zurücknehmen | content:publish_own oder content:publish_any | Optional | Erforderlich | Erzwungen | content:beforeUnpublish, content:afterUnpublish |
| Planen | content:publish_own oder content:publish_any | Optional | Erforderlich | Erzwungen | content:beforeSchedule, content:afterSchedule |
| Planung aufheben | content:publish_own oder content:publish_any | Nicht akzeptiert | Nicht akzeptiert | Erzwungen | content:afterUnschedule |
| Entwurf verwerfen | content:edit_own oder content:edit_any | Optional | Erforderlich | Erzwungen | Keine |
| In den Papierkorb verschieben | content:delete_own oder content:delete_any | Nicht akzeptiert | Nicht akzeptiert | Erzwungen | content:beforeDelete, content:afterDelete |
| Aus dem Papierkorb wiederherstellen | content:edit_own oder content:edit_any | Nicht akzeptiert | Nicht akzeptiert | Nicht erzwungen | content:afterRestore |
| Dauerhaft löschen | content:delete_permanent | Nicht akzeptiert | Nicht akzeptiert | Nicht erzwungen | content:afterDelete |
| Eine Revision wiederherstellen | content:edit_own oder content:edit_any | Nicht akzeptiert | Nicht akzeptiert | Nicht erzwungen | Keine |
Das Ereignis content:afterDelete setzt permanent auf false, wenn ein Eintrag in den Papierkorb verschoben wird, und auf true
nach dauerhaftem Löschen. Erfolgreiche After-Hooks laufen nach der Zustandsänderung und können nach dem
Senden der Antwort laufen. Ein Plugin kann Speichern, Veröffentlichen, Veröffentlichung zurücknehmen, Planen oder In-den-Papierkorb-Verschieben aus
dem entsprechenden Before-Hook ablehnen.
Wenn die geplante Veröffentlichung fällig wird, verwendet sie die Publish-Hooks. Wenn ein
content:beforePublish-Hook diesen geplanten Versuch ablehnt, löscht EmDash den Zeitplan und führt
content:afterUnschedule aus.
Konflikte und Wiederholungen
Verwenden Sie das von jedem Lese- oder Schreibvorgang zurückgegebene _rev für die nächste geschützte Operation. EmDash lehnt ein
veraltetes Token ab, anstatt eine gleichzeitige Änderung zu ersetzen. Lesen Sie den Eintrag erneut, prüfen Sie den neueren
Zustand und entscheiden Sie dann, ob Sie es erneut versuchen.
Eine Fehlerantwort beweist nicht immer, dass sich kein Zustand geändert hat. Wenn eine Verbindung endet, bevor der Client eine Antwort erhält, lesen Sie den Eintrag, bevor Sie eine Lebenszyklusoperation erneut versuchen. Das verhindert auch, dass ein Wiederholungsversuch die Arbeit eines anderen Editors ersetzt.
Die Revisionswiederherstellung speichert den wiederhergestellten Inhalt und seine Audit-Revision zusammen. Wenn einer der Schreibvorgänge fehlschlägt, bewahrt EmDash den Inhalt und die Revisionshistorie von vor der Anfrage.
Siehe die REST-API-Referenz für HTTP-Anfrage- und -Antwortschemas, die MCP-Server-Referenz für Tool-Eingaben und die Hook- Referenz für Ereignisnutzlasten.