Redaktioneller Workflow

Seiten verwenden vier Workflow-Status:

• draft
• in_review
• published
• archived

Neue Seiten beginnen als draft.

• Inhalt in Bearbeitung
• nicht öffentlich
• Editoren können Inhalte in diesem Zustand bearbeiten

• bereit zur Prüfung
• nicht öffentlich
• Editoren können den Seiteninhalt nicht weiter bearbeiten, bis die Seite zurück in draft verschoben wird

• öffentlich
• auf der öffentlichen Site routbar
• die Seitensichtbarkeit wirkt weiterhin zusammen mit den Sichtbarkeitsregeln auf Blockebene innerhalb der Seite

• aus dem Live-Betrieb genommen
• nicht öffentlich
• kann von einer berechtigten Rolle zurück in draft verschoben oder erneut veröffentlicht werden

Erlaubte Aktionen:

• draft -> in_review
• in_review -> draft
• published -> draft
• archived -> draft

Nicht erlaubt:

• Veröffentlichen
• Archivieren

Erlaubte Aktionen für zugewiesene Sites:

• draft -> in_review
• draft -> published
• in_review -> draft
• in_review -> published
• in_review -> archived
• published -> draft
• published -> archived
• archived -> draft
• archived -> published

super_admin hat dieselben Workflow-Befugnisse wie site_admin, jedoch über die gesamte Installation hinweg.

Nur Seiten mit dem Status published sind öffentlich.

• draft-Seiten liefern 404
• in_review-Seiten liefern 404
• archived-Seiten liefern 404

Dies gilt für normale öffentliche Routen, Multisite-Routing und lokalisierte Routen.

Der Workflow-Status der Seite und der Block-Status sind getrennt. Die normale Aktion Publish unter Seite bearbeiten -> Übersicht veröffentlicht nur den Seitendatensatz. Sie veröffentlicht nicht stillschweigend Entwurfs- oder In-Review-Blöcke innerhalb der Seite. Wenn eine Seite unveröffentlichte seiteneigene Blöcke hat, öffnet die Veröffentlichungsaktion ein Modal mit einer nicht angehakten Option Also publish all unpublished page-owned blocks. Bleibt sie nicht angehakt, wird das Nur-Seite-Verhalten beibehalten; wird sie angehakt, werden berechtigte seiteneigene Blöcke in derselben Workflow-Aktion veröffentlicht.

Der Übersichts-Tab zeigt außerdem einen Unpublished page content-Hinweis, wenn seiteneigene Blöcke noch Entwurf oder in Prüfung sind. Publish page-owned blocks veröffentlicht nur diese seiteneigenen Blöcke und ändert den Workflow-Status der Seite nicht.

Shared-Slot-Inhalte sind von diesen Veröffentlichungs-Workflows für seiteneigene Blöcke ausgenommen. Shared-Slot-gestützte Header-, Footer- oder andere Slots müssen separat geprüft und veröffentlicht werden; WebBlocks CMS kaskadiert die Seitenveröffentlichung nicht in Shared-Slot-Blockbäume.

Der Workflow-Zustand beeinflusst auch, wer den Seiteninhalt weiter bearbeiten darf.

• Editoren können den Seiteninhalt nur bearbeiten, während sich die Seite in draft befindet
• sobald eine Seite draft verlässt, erfordert die Inhaltsbearbeitung einen site_admin oder super_admin oder eine Workflow-Rückkehr zu draft
• site_admin- und super_admin-Benutzer können über die Workflow-Zustände hinweg weiterarbeiten, die sie verwalten dürfen

1. der Editor erstellt eine Seite in draft
2. der Editor stellt den Inhalt fertig und reicht ihn zur Prüfung ein
3. der Site-Admin oder Super-Admin prüft die Seite
4. der Site-Admin oder Super-Admin veröffentlicht die Seite
5. spätere Aktualisierungen können die Seite zurück in draft verschieben und dann erneut durch die Prüfung führen

Interne Arbeitsabläufe können Aktualisierungen vorbereiten, ohne die veröffentlichte Seite auf draft zurückzusetzen. Eine separate Staging-Entwurfsseite wird mit der veröffentlichten Quellseite verknüpft. Die Quelle bleibt unter ihrer bisherigen Adresse öffentlich; die Staging-Seite lässt sich unter /webadmin/pages/{page}/preview prüfen.

Die Übernahme erfolgt ausdrücklich. Dabei kopiert WebBlocks CMS freigegebene seiteneigene Slot-Inhalte zur veröffentlichten Quelle, setzt übernommene Blöcke auf published und behält Adresse und Status der Quelle bei. Durch Shared Slots bereitgestellte Bereiche bleiben ausgeschlossen. Nach den Sicherheitsversionen vor und nach der Übernahme wird die technische Staging-Seite in derselben Transaktion gelöscht. Ein ungenutzter aktiver Staging-Entwurf kann über die eigene Internal-Content-API-Aktion verworfen werden, ohne allgemeine Seitenlöschrechte zu vergeben.

Wählen Sie auf einer vorhandenen Entwurfs- oder Staging-Seite in den Seiteneinstellungen oder einem unterstützten seiteneigenen Blockformular Vorschaufenster öffnen und dann Vorschau aktualisieren. Der normale Seitenrenderer zeigt unterstützte ungespeicherte Werte des offenen Formulars mit dem übrigen gespeicherten Entwurf. Andere offene Formulare werden nicht einbezogen. Aktualisieren speichert keine Inhalte, erstellt keine Version und übernimmt keine Staging-Aktualisierung. Wiederherstellungsprüfpunkte arbeiten unabhängig. Erstellen Sie für eine veröffentlichte Seite zuerst eine Staging-Aktualisierung.

Wählen Sie eine aktivierte Inhaltssprache und Desktop (1024 px) oder Telefon (390 px). Nach einem Sprachwechsel müssen Sie erneut aktualisieren. Die Bearbeitungssprache des Formulars bleibt unverändert: Ungespeicherter türkischer Text wird durch die Vorschauauswahl nicht englisch. Eine fehlende Seitenübersetzung führt zu einem ausdrücklichen Fehler; vorhandene Übersetzungsrückfälle der Blöcke bleiben erhalten.

Änderungen ausstehend bedeutet, dass die Anzeige veraltet sein kann. Nach einem Fehler bleibt der Zeitpunkt des letzten erfolgreichen Renderns sichtbar. Validierungsfehler, nicht verfügbare Quellen, Verbindungsabbruch und abgelaufener Zugriff erhalten die Formularwerte. Beheben Sie das Problem und aktualisieren Sie erneut; laden Sie ein unfertiges Formular nicht allein für einen Wiederholungsversuch neu. Dynamic Content verwendet konfigurierte Zuordnungen, Filter, Sortierung, Seitennavigation und Leer-/Fehlerverhalten. Tippen und Öffnen des Panels fragen keine Quellen ab.

Das private Panel isoliert die Ausgabe vom Editor. Links, verfasste Skripte, eingebettete Frames und Formularsendungen sind deaktiviert; native Seitennavigation von Sammlungen bleibt verfügbar. Gallery-, Inline-Kindblock-, Plugin- und Embedded-Application-Formulare, neue Blöcke, Datei-Uploads sowie Änderungen an Blocktyp, Slot, Elternblock, Reihenfolge oder Status erfordern vorheriges Speichern. Nicht unterstützte Vorgänge werden erläutert. Gespeicherte Vorschau in neuem Tab bleibt auch auf schmalen Bildschirmen verfügbar und zeigt nur gespeicherte Werte. Speichern und Veröffentlichen bleiben getrennte Aktionen.

Auf vorhandenen Entwurfs- und Staging-Seiten sichern Wiederherstellungsprüfpunkte unfertige Werte der Seiteneinstellungen und seiteneigenen Blockformulare, einschließlich lokalisierter Rich-Text-Formatierung und ausgewählter Medienreferenzen. Warten Sie auf Wiederherstellungsprüfpunkt bestätigt, bevor Sie sich darauf verlassen. Bei ausstehender oder fehlgeschlagener Bestätigung ist die letzte Eingabe möglicherweise nicht geschützt. Lassen Sie den Tab offen oder speichern Sie normal.

Kehren Sie nach Neuladen oder einer Unterbrechung im selben Tab zum Editor zurück und melden Sie sich gegebenenfalls als derselbe Benutzer an. Wählen Sie Formularwerte wiederherstellen, Prüfpunkt verwerfen oder Mit gespeichertem Inhalt fortfahren. Wiederherstellen füllt das Formular zur Prüfung und zum ausdrücklichen Speichern. Fortfahren behält den früheren Prüfpunkt und pausiert den Schutz neuer Änderungen, bis Sie wiederherstellen oder verwerfen. Verwerfen entfernt nur den betreffenden Prüfpunkt und ändert keine gespeicherten Inhalte.

Wurde die gespeicherte Seite andernorts geändert, prüfen und bestätigen Sie vor der Wiederherstellung den aktuellen Inhalt. Speichern prüft spätere Konflikte erneut. Aktueller Website-Zugriff, Rollenrechte, Kontostatus, Inhaltssprache und Workflow werden durchgehend geprüft. Benutzer, Formulare, Sprachen und Bearbeitungssitzungen haben getrennte Prüfpunkte.

Wiederherstellung erstellt keine Version und veröffentlicht nichts. Sie umfasst vorhandene Entwurfs- und Staging-Seiten; erstellen Sie vor dem Bearbeiten veröffentlichter Seiten eine Staging-Aktualisierung. Shared Slots, neue ungespeicherte Seiten, Datei-Uploads und Zugangsdatenfelder sind ausgeschlossen. Ein moderner Browser mit Tab-Isolierung ist erforderlich; fehlende Unterstützung oder Verfügbarkeit wird ausdrücklich angezeigt.

Prüfpunkte sind auf 256 KiB und 512 Formularfelder sowie 32 unfertige Bearbeitungssitzungen je Benutzer begrenzt. Sie verfallen sieben Tage nach der letzten Aktualisierung. Erfolgreiches Speichern und ausdrückliches Verwerfen entfernen den passenden Prüfpunkt; fehlgeschlagenes Speichern erhält ihn. Der Scheduler entfernt abgelaufene Prüfpunkte täglich. Betreiber können auch php artisan webblocks:editor-recovery:prune ausführen.