Systemseiten

Mit Systemseiten können Sie Fehler- und Plugin-Ansichten für Besucher mit demselben Layout und denselben gemeinsam genutzten Bereichen gestalten wie die übrige Website. Sie finden sie unter Seiten am Abzeichen System. Der Seitentypfilter trennt Inhalts- und Systemdatensätze. Das Menü „System“ bleibt für Betriebseinstellungen zuständig.

1. Wählen Sie unter „Seiten“ eine Website aus und klappen Sie Systemseiten über die Überschrift mit dem Pfeil auf. Die Überschrift lässt sich auch per Tastatur bedienen.
2. Wählen Sie Entwurf vorbereiten neben einer integrierten Fehleransicht oder einer von einem aktivierten Plugin deklarierten Ansicht.
3. Der Entwurf enthält native bearbeitbare Startblöcke mit übersetzter Überschrift und Einleitung. Fehlerdesigns enthalten außerdem den üblichen Fehlertext. Der Startinhalt für 404 enthält einen Button-Link zur Startseite. Öffnen Sie Hauptbereich → Blöcke bearbeiten, um den Inhalt zu ändern.
4. Wählen Sie das Seitenlayout aus. Ordnen Sie mit den vorhandenen Steuerelementen kompatible gemeinsam genutzte Kopf-, Fuß-, Seitenleisten- oder andere Bereiche zu.
5. Ergänzen Sie umgebende Inhalte und Übersetzungen und öffnen Sie die Vorschau.
6. Veröffentlichen Sie das Design ausdrücklich, wenn es fertig ist. Das Vorbereiten oder Speichern eines Entwurfs ändert die öffentliche Ansicht nicht.

Der Editor verlangt die bestehenden Seitenberechtigungen für die ausgewählte Website. Berechtigungen für gemeinsam genutzte Bereiche bleiben separat. Bei einer bereits vorbereiteten Ansicht öffnet sich das bestehende Design. Wiederholtes Vorbereiten erzeugt keine Duplikate. Sie können ein Design archivieren oder löschen, um die integrierte Darstellung wiederherzustellen. Es hat keinen eigenen öffentlichen Slug und erscheint weder in Suchergebnissen noch in automatischen Seitenlisten oder der Sitemap. Ein Systemseitendesign kann weder dupliziert noch zu einer anderen Website verschoben werden. Bereiten Sie stattdessen ein eigenes Design auf der Zielwebsite vor. Website-Importe behalten die Ansichtskennung bei und lassen importierte Designs im Entwurf. Die bestehende pfadbasierte Website-Übertragung lehnt Pakete mit Systemseiten ab. Exportieren Sie dafür ausschließlich gewöhnliche Inhaltsseiten.

Der Tab „Einstellungen“ nennt die Ansicht mit ihrem lesbaren Namen. Klappen Sie Technische Details nur auf, wenn Sie die interne Zuordnungskennung benötigen. Ist die Plugin-Definition nicht verfügbar, wird der gespeicherte Seitentitel verwendet.

Beim ersten Vorbereiten werden Seite, Blöcke, Übersetzungen und erste Revision zusammen gespeichert. Öffnen Sie Hauptbereich → Blöcke bearbeiten. Der vorbereitete Text ist bereits eingetragen und lässt sich mit den üblichen Blockfunktionen bearbeiten. Die Vorschau zeigt die gespeicherten Blöcke mit Ihren Änderungen. Beim erneuten Öffnen eines Designs bleiben diese Änderungen erhalten.

Standardblöcke sind gewöhnliche Hero-, Header-, Plain-Text- oder Button-Link-Datensätze mit SQL-Übersetzungszeilen und typisierten Einstellungen. Weder eine JSON-Vorlage noch ein separater Plugin-Inhaltsspeicher ist dafür zuständig. Es gelten derselbe Blockeditor und dieselbe API wie bei anderen Seiten.

Die jeweilige Funktion bleibt für Formular, Ergebnisse und Verarbeitung zuständig. Redaktionelle Blöcke im Hauptbereich stehen vor dem Funktionsinhalt. Erforderliche Plugin-Formulare und Ergebnisse lassen sich weder durch Löschen von Blöcken noch durch Deaktivieren des Hauptbereichs entfernen. Plugin-Vorschauen zeigen gespeicherte native redaktionelle Blöcke und einen kleinen beschrifteten Laufzeitplatzhalter ohne echte Kunden-, Konto-, Zahlungs- oder Token-Daten. Vorschauen integrierter Fehlerseiten zeigen den gespeicherten redaktionellen Inhalt ohne Formularplatzhalter. Benutzerdefinierter Fehlertext erhält keine zweite unveränderliche Standardmeldung. Blöcke gemeinsam genutzter Bereiche behalten ihren separaten Veröffentlichungsablauf. Das Plugin muss seine Unterstützung ausdrücklich deklarieren. Eine öffentliche Route allein macht eine Ansicht noch nicht zur Systemseite.

Der Kern stellt Seite nicht gefunden (404) und Wartung (503) bereit. Aktualisierte Versionen von Campaigns, Appointments, Memberships und Commerce deklarieren ihre Bestätigungs-, Konto-, Warenkorb- und Zahlungsansichten. Ein Design je Ansicht gilt für alle zugehörigen Laufzeitdatensätze.

Veröffentlichen Sie die Seite und ihre Inhaltsblöcke über den normalen Workflow. Die integrierte öffentliche Fehleransicht bleibt aktiv, bis das Design veröffentlichte Inhalte im Hauptbereich enthält.

Ein veröffentlichtes 404-Design behält die tatsächliche 404-Antwort und den Schutz vor Indexierung bei. JSON-Fehler und eine eigene 404-Vorlage der Hostanwendung verhalten sich wie bisher. Wenn ein benutzerdefiniertes Fehlerdesign nicht gerendert werden kann, verwendet das CMS seine integrierte Ersatzansicht.

Vor einer CMS-Aktualisierung wird das veröffentlichte 503-Design der primären Website als HTML gespeichert. So kann die Wartungsantwort ohne Anwendung oder Datenbank ausgegeben werden und behält HTTP 503 und den Hinweis zum erneuten Versuch bei. Laravels Wartungssperre vor dem Anwendungsstart gilt installationsweit. Andere Domains verwenden deshalb die vorbereitete Wartungsausgabe der primären Website. Sie enthält das ausgewählte Layout und die gemeinsam genutzten Bereiche, lässt aber die Such- und Einwilligungsdialoge des CMS aus. Ist kein nutzbares veröffentlichtes Design vorhanden, verwendet das CMS die statische integrierte Wartungsvorlage. Das Vorbereiten einer Systemseite allein schaltet die Website nicht in den Wartungsmodus.

Suche und Cookie-Einstellungen bleiben Funktionen der aktuellen Seite und sind daher keine Systemseiten. Alte Such- und Einstellungsadressen leiten zur lokalisierten Startseite weiter und öffnen den passenden Dialog. Ihre JSON- und Formularendpunkte bleiben technische Endpunkte. Siehe Suche und Cookies und Datenschutz.