Seitenlayouts

Seitenlayouts sind Definitionen auf Installationsebene, die die Wahl der äußeren öffentlichen Shell und die verwalteten Slot-Wrapper für Seiten steuern.

Umfang von V1

  • Admin-Pfad: Admin -> System -> Page Layouts
  • Zugriff: nur super_admin
  • V1 unterstützt Auflisten, Erstellen, Bearbeiten, Aktivieren, Deaktivieren, Sortieren, CRUD für verwaltete Seitenlayout-Slots, den Slot-Vergleich in „Seite bearbeiten“ sowie das sichere Anwenden fehlender Slots
  • V1 unterstützt das Löschen von Systemlayouts nicht
  • Seiten speichern das ausgewählte Layout-Handle in dieser Version aus Gründen der Abwärtskompatibilität weiterhin in pages.settings.public_shell
  • Die sichtbaren Seitenlayout-Felder sind Name, Handle, Description, Status, Sort Order und Body Class
  • Shell Type, Slot Schema JSON und Wrapper Schema JSON sind veraltete Kompatibilitätsfelder und nicht mehr Teil des Admin-Formulars
  • Rohes Slot Schema JSON und Wrapper Schema JSON sind nicht mehr das Bearbeitungsmodell im Admin-Bereich

Integrierte Layouts

  • default / Default Layout: Standard-Shell für öffentliche Seiten
  • docs / Docs Layout: Docs-Shell mit Regionszuordnung für Header, Seitenleiste, Hauptbereich und Footer

Diese integrierten Layouts bleiben abwärtskompatibel mit älteren Seiten, Importen, Exporten und dem öffentlichen Rendering.

Jedes integrierte Layout legt jetzt außerdem verwaltete Seitenlayout-Slots an:

  • default: header, main, sidebar, footer
  • docs: header, sidebar, main, footer

So funktioniert das Rendering

  • Eine Seite speichert ein Seitenlayout-Handle in public_shell
  • Die Laufzeit löst dieses Handle in ein verwaltetes Seitenlayout auf, sofern eines existiert
  • Das aufgelöste Seitenlayout kann eine validierte body_class zum öffentlichen <body>-Element beitragen
  • Die Laufzeit löst Slot-Wrapper aus den relationalen page_layout_slots auf, sofern verfügbar
  • Jeder Seitenlayout-Slot verweist auf eine veröffentlichte CMS-SlotType-Zeile und definiert Wrapper-Metadaten wie Element, id, Klassen und vertrauenswürdige Wrapper-Snippets
  • Sind relationale Seitenlayout-Slots nicht verfügbar, halten integrierte Fallback-Definitionen das Rendering von default und docs stabil

In V1 verwenden benutzerdefinierte Layouts weiterhin das bestehende öffentliche Shell-Verhalten von default oder docs. Die Laufzeit leitet dieses Verhalten aus Kompatibilitätsgründen konservativ aus den verwalteten Slot-Definitionen ab.

Verwaltete Seitenlayout-Slots

Seitenlayout-Slots sind die verwalteten Regionsdatensätze, die einem einzelnen Seitenlayout zugeordnet sind.

  • Admin-Pfad: Admin -> System -> Page Layouts -> Edit -> Page Layout Slots
  • Slot-Typen sind der Katalog zum Hinzufügen von Seitenlayout-Slots
  • Jeder Seitenlayout-Slot speichert slot_type_id, slot_name, label, description, html_element, html_id, html_classes, before_html, start_html, end_html, after_html, is_required, is_active, is_system und sort_order
  • Die Admin-Bearbeitung gruppiert diese Felder in Slot Identity, Wrapper Markup, Advanced Trusted Layout HTML und Status / Ordering
  • Die Validierung erlaubt nur sichere HTML-ids, sichere durch Leerzeichen getrennte Klassen und vertrauenswürdige Wrapper-Snippets; Inhalte mit Skripten, Event-Attributen, javascript:, iframe, object und embed werden abgelehnt
  • Systemlayouts halten ihre System-Slot-Zuordnung stabil: System-Seitenlayout-Slots erlauben keine Änderung des zugrunde liegenden Slot-Namens oder Slot-Typs
  • Seitenlayout-Slots, die weder System-Slots noch erforderlich sind, können entfernt werden
  • CSS Classes erwartet durch Leerzeichen getrennte Klassen-Tokens
  • Wrapper-Klassen können Layout-Hinweise wie wb-sidebar, wb-dashboard-main oder wb-stack enthalten, wenn diese Klassen zum ausgewählten Layout passen
  • Das Sticky-Verhalten der öffentlichen Navbar sollte aus dem mitgelieferten wb-navbar-Primitiv kommen, nicht aus Sticky-Regeln für den Header auf Site-Ebene
  • Enthält ein öffentlicher Standard-Header-Slot nur einen Navbar-Block, hebt das CMS den Slot-Wrapper auf die nav.wb-navbar-Wurzel an, sodass die Navbar ohne sitespezifisches CSS haften bleibt
  • Before Slot HTML wird vor dem Slot-Wrapper gerendert
  • Slot Start HTML wird innerhalb des Wrappers vor den Blöcken gerendert
  • Slot End HTML wird innerhalb des Wrappers nach den Blöcken gerendert
  • After Slot HTML wird nach dem Slot-Wrapper gerendert
  • Erweitertes vertrauenswürdiges Layout-HTML ist ausschließlich für Layout-Markup in Wrapper-Nähe gedacht, nicht für Skripte

Vergleichen und Anwenden in „Seite bearbeiten“

  • „Seite bearbeiten“ zeigt jetzt eine Page Layout Slots-Karte in der Nähe der Slot-Verwaltung
  • Die Karte vergleicht die aktiven verwalteten Seitenlayout-Slots des ausgewählten Seitenlayouts mit den Seiten-Slots der aktuellen Seite
  • Der Vergleich meldet mindestens:
  • vom ausgewählten Seitenlayout definierte Layout-Slots
  • bereits auf der Seite vorhandene Seiten-Slots
  • fehlende Layout-Slots
  • zusätzliche Seiten-Slots, die das ausgewählte Seitenlayout nicht definiert
  • deaktivierte Seiten-Slots
  • durch Shared Slots gestützte Seiten-Slots
  • Add Missing Layout Slots erscheint nur, wenn fehlende Layout-Slots existieren
  • Die Aktion ist explizit. Das Speichern normaler Seiteneinstellungen synchronisiert Slots nicht stillschweigend.

Sicherheitsregeln

  • Add Missing Layout Slots erstellt auf der aktuellen Seite nur fehlende aktive Seitenlayout-Slots
  • Es löscht keine zusätzlichen Seiten-Slots
  • Es löscht keine Blöcke
  • Es ändert kein bestehendes page_slots.source_type
  • Es leert keine bestehende shared_slot_id
  • Es aktiviert deaktivierte Seiten-Slots nicht automatisch
  • Es sortiert oder überschreibt bestehende Seiten-Slots nicht stillschweigend
  • Zusätzliche Seiten-Slots bleiben aus Sicherheitsgründen erhalten und werden gemeldet, auch wenn das ausgewählte Seitenlayout sie nicht definiert
  • Die Shared-Slot-Kompatibilität bleibt exakt anhand des gespeicherten public_shell-Handles

Standardwerte für neue Seiten

  • Neue Seiten verwenden nach Möglichkeit die aktiven verwalteten Seitenlayout-Slots des ausgewählten Seitenlayouts
  • Der veraltete slot_schema-Fallback bleibt nur als sicherer Kompatibilitäts-Fallback bestehen, wenn relationale oder integrierte verwaltete Slot-Definitionen nicht verfügbar sind
  • Neue Seiten sollten nicht erfordern, dass Administratoren die Standard-Slots nach der Wahl eines Seitenlayouts manuell hinzufügen

Layoutwechsel bei bestehenden Seiten

  • Das Ändern des ausgewählten Seitenlayouts auf einer bestehenden Seite löscht oder überschreibt Slots beim normalen Speichern nicht automatisch
  • Nach dem Speichern zeigt „Seite bearbeiten“ den aktualisierten Vergleich, damit Editoren fehlende oder zusätzliche Slots sicher prüfen können
  • Die aktuelle Version bevorzugt bewusst das explizite Add Missing Layout Slots gegenüber automatischen Änderungen

Body Class

  • Body Class ist eine optionale, durch Leerzeichen getrennte Token-Liste, die dem öffentlichen <body> hinzugefügt wird
  • Die integrierten vorbelegten Werte sind derzeit layout-default und layout-docs
  • Das öffentliche Rendering behält die Basisklasse wb-public-body und hängt die Body-Klassen des Seitenlayouts an, sofern verfügbar
  • Layoutspezifisches CSS kann Kombinationen wie body.layout-docs plus die von Seitenlayout-Slots definierten Slot-ids und -Klassen ansprechen
  • Bevorzugen Sie für sticky öffentliche Header einen Navbar-Block; das CMS hebt Standard-Header-Slots mit einer einzelnen Navbar auf die nav.wb-navbar-Wurzel an, sodass WebBlocks UI den Sticky-Versatz und das Stapelverhalten steuert

Zuständigkeitsgrenzen

  • Das Seitenlayout besitzt die Wahl der äußeren öffentlichen Shell
  • Das Seitenlayout besitzt außerdem die öffentlichen Body-Class-Tokens für diese Shell
  • Seitenlayout-Slots besitzen die Wrapper-Metadaten und die Sortierung der Regionen
  • Seitenlayout-Slots besitzen für jede Region das öffentliche Wrapper-Element, die id, die Klassen und optionales vertrauenswürdiges HTML in Wrapper-Nähe
  • Slot-Namen besitzen die Wrapper-Semantik der Regionen wie header, main, sidebar und footer
  • Blöcke besitzen den Inhalt, der innerhalb dieser Wrapper gerendert wird
  • Das Sticky-Verhalten der Navbar bleibt in der Verantwortung von WebBlocks UI .wb-navbar, nicht der CMS-Seitenlayouts

Unbekannte oder fehlende Layouts

  • Bestehende Seiten werden nicht von public_shell wegmigriert
  • Unbekannte Layout-Handles bleiben unverändert gespeichert
  • Die Admin-Bearbeitung bleibt sicher, indem sie das aktuelle Legacy-Handle als erhaltene Option anzeigt
  • Das öffentliche Rendering fällt sicher zurück, statt abzustürzen
  • Unbekannte Handles fallen in V1 sicher auf das Standard-Laufzeitverhalten zurück

Shared-Slot-Kompatibilität

Die Shared-Slot-Kompatibilität bleibt in V1 konservativ.

  • Die Admin-Oberflächen für Shared Slots präsentieren diese Einschränkung jetzt als Page Layout, während das gespeicherte Kompatibilitätsfeld in dieser Version aus Gründen der Abwärtskompatibilität public_shell bleibt
  • Eine exakte Übereinstimmung des public_shell-Handles ist erforderlich, wenn ein Shared Slot public_shell setzt
  • Ein leeres public_shell bleibt generisch
  • Ein benutzerdefiniertes Layout-Handle, das docs-artiges Laufzeitverhalten wiederverwendet, passt nicht automatisch zu Shared Slots, die auf docs eingeschränkt sind
  • Das Hinzufügen fehlender Layout-Slots erstellt neue Seiten-Slots standardmäßig als Page Content und erweitert das Kompatibilitätsverhalten von Shared Slots nicht

Portabilitätsgrenze

  • Site-Export/-Import und Klonen übertragen weiterhin public_shell-Handles auf Seitenebene als Seitenkonfiguration
  • Seitenlayout-Definitionen und Seitenlayout-Slot-Definitionen auf Installationsebene sind in V1 nicht im Site-Export/-Import enthalten
  • Verwendet eine übertragene Seite ein benutzerdefiniertes Layout-Handle, sollte die Zielinstallation für das beabsichtigte Verhalten ein passendes Seitenlayout-Handle besitzen
  • Existiert auf der Zielinstallation kein passendes Layout, fällt das Rendering sicher zurück