Grundkonzepte

WebBlocks CMS verwendet ein explizites relationales Inhaltsmodell, das auf Seiten, Layouts, Slots und Blöcken aufbaut.

Die Kernstruktur lautet:

Page -> Layout -> Slots -> Blocks

• Eine Seite besitzt Routing, Site-Kontext, Workflow-Status und Layout-Auswahl.
• Eine Seite kann außerdem relationale Page-Asset-Zeilen für seitenbezogene CSS- und JS-Dateireferenzen besitzen.
• Ein Layout definiert die verfügbaren strukturellen Bereiche.
• Slots sind benannte Platzierungsbereiche innerhalb des Layouts, etwa header, main, sidebar und footer.
• Blöcke sind die eigentlichen Inhaltseinheiten, die in Slots platziert und, sofern unterstützt, unter anderen Blöcken verschachtelt werden.

Seiten speichern kein freiformatiges Page-Builder-JSON. Inhalte und Beziehungen werden in relationalen Tabellen gehalten, damit die Struktur explizit und nachvollziehbar bleibt.

• Page Assets sind ein zentrales CMS-Feature für seitenbezogene CSS- und JS-Dateireferenzen.
• Page Assets werden relational in page_assets gespeichert, nicht innerhalb des pages.settings-JSON.
• V1 akzeptiert nur lokale Installationspfade unterhalb von /site/....
• Externe URLs, Inline-CSS, Inline-JS, Query-Strings, Fragmente, Pfad-Traversal und nicht passende Dateiendungen werden abgelehnt.
• CSS wird derzeit nur im Head des öffentlichen Dokuments gerendert.
• JS wird derzeit nur im Head des öffentlichen Dokuments mit defer gerendert.
• CMS-eigene öffentliche Assets liegen unter public/cms/.
• public/storage ist der öffentliche Laravel-Storage-Symlink für storage/app/public und ist von Site-/Seiten-Override-Assets getrennt.
• Die kanonischen öffentlichen Asset-Pfade sind public/site/{site_handle}/css/site.css, public/site/{site_handle}/js/site.js, public/site/{site_handle}/pages/{page_slug}/page.css und public/site/{site_handle}/pages/{page_slug}/page.js.
• Page Assets werden nur für die besitzende öffentliche Seite gerendert und sind von Admin-Layouts und nicht zugehörigen Seiten ausgeschlossen.
• Seiten-Revisionen, Duplizieren, Verschieben sowie Site-Export oder -Import behandeln Page Assets als seiteneigene Konfiguration.
• Der Einzelseiten-JSON-Import kann ebenfalls page_assets-Zeilen anlegen, wenn die Payload gültige lokale /site/...-Pfade verwendet, die die bestehenden Page-Asset-Validierungsregeln bestehen.
• Die Suchindexierung behandelt Page-Asset-Pfade nicht als Seiteninhalt.

• Eine Seite gehört zu jedem Zeitpunkt genau einer Site.
• Das normale Edit Page-Formular hält Site für bestehende Seiten schreibgeschützt.
• Das Duplizieren einer Seite erzeugt einen neuen Seitendatensatz in derselben Site oder einer anderen zugänglichen Site.
• Site-übergreifende Seitenverschiebungen verwenden einen dedizierten Move to another site-Workflow statt einer Inline-Feldänderung.
• Die Seitenduplizierung verwendet einen dedizierten Duplicate page-Workflow, statt auf dem normalen Seitenformular aufzusetzen.
• Die Verschiebung läuft als kontrollierte Transaktion, damit pages.site_id und page_translations.site_id gegenüber dem zusammengesetzten Fremdschlüssel (page_id, site_id) gültig bleiben.
• Das Duplizieren startet die neue Seite immer als Entwurf und kopiert den Inhaltsstand, ohne die Revisionshistorie der Quellseite zu kopieren.
• Die Verschiebung bewahrt die Seiten-ID, Übersetzungen, Slots, seiteneigene Blöcke, Blockübersetzungen, Reihenfolge, Workflow-Status und Revisionshistorie.
• Das Duplizieren bewahrt Layout, Übersetzungen, Slots, seiteneigene Blöcke, verschachtelte Blockbeziehungen, Blockübersetzungen und kompatible Shared-Slot-Referenzen, erzeugt aber eine neue Seiten-ID.
• Pfadkonflikte in der Ziel-Site sind in der aktuellen Version blockierende Validierungsfehler.
• Shared-Slot-Referenzen müssen auf kompatible Shared Slots mit demselben Handle in der Ziel-Site umgemappt werden können, andernfalls wird die Verschiebung blockiert.
• Das Duplizieren innerhalb derselben Site bewahrt bestehende Shared-Slot-Referenzen.
• Das site-übergreifende Duplizieren mappt nur kompatible Shared Slots mit demselben Handle in der Ziel-Site um.
• Wenn ein site-übergreifendes Duplikat einige Shared-Slot-gestützte Slots nicht ummappen kann, ist das Standardverhalten weiterhin, das Duplizieren zu blockieren.
• Der Duplizierungs-Workflow kann jetzt gezielt nur die inkompatiblen duplizierten Seiten-Slots deaktivieren, statt eine ungültige site-übergreifende Shared-Slot-Referenz zu persistieren.
• Dieser Opt-in-Fallback schreibt den duplizierten Seiten-Slot als disabled, leert shared_slot_id, lässt die Quellseite unverändert und kopiert in dieser Version keine Shared-Slot-Blockbäume in die duplizierte Seite.
• Site-weite Portabilitätswerkzeuge wie Export / Import und Site Clone bleiben von Seitenverschiebungen und Seitenduplizierung getrennt.
• Admin -> Pages -> Import Page ist ein seitenbezogener Portabilitäts-Workflow. Er erzeugt eine neue Seite aus einer dokumentierten webblocks.cms.page.v1-JSON-Payload und ist bewusst vom site-weiten Export / Import getrennt.
• Der V1-Einzelseiten-Import erzeugt immer eine neue Seite und importiert sie immer als Entwurf.
• Der V1-Einzelseiten-Import importiert die Revisionshistorie der Quellseite nicht.
• Shared-Slot-gestützte Seiten-Slots im Einzelseiten-Import müssen über ein stabiles Handle auf einen kompatiblen Shared Slot der Ziel-Site verweisen. Der Importer legt in V1 keine Shared Slots automatisch an.

• Die Produktidentität von WebBlocks CMS ist in der Admin-Shell fest verankert und stammt aus App\Support\WebBlocks.
• Die Projektidentität ist installationsweiter Admin-Kontext, der in Admin -> System -> Settings konfiguriert wird.
• Die Projektidentität umfasst derzeit Project Name und Project Tagline.
• Die Projektidentität wird nur für den Kontext der Admin-Topbar und für Admin-Browsertitel verwendet.
• Die Projektidentität ändert weder die feste WebBlocks-CMS-Sidebar-Marke, den Versions-Footer der Sidebar, öffentliche Site-Metadaten, das öffentliche Favicon, den öffentlichen Suchumfang noch die SEO-Werte von Seitenübersetzungen.
• Site-Datensätze besitzen die öffentliche Identität und die Metadaten.
• sites.name bleibt der interne Admin-Datensatzname.
• display_name ist die optionale Überschreibung des öffentlichen Site-Namens.
• tagline ist optionaler öffentlicher Text für die Site.
• seo_title, seo_description und seo_keywords sind Fallback-Metadaten auf Site-Ebene.
• favicon_media_id und social_image_media_id sind optionale Medienreferenzen auf Site-Ebene für die öffentliche Head-Ausgabe.
• site_variables sind optionale, wiederverwendbare Klartextwerte auf Site-Ebene für die kontrollierte öffentliche Token-Ersetzung.
• Zeilen von Seitenübersetzungen besitzen außerdem lokalisierte SEO-Override-Felder wie seo_title, seo_description, seo_keywords, og_title, og_description und og_image_media_id.
• Das hält öffentliche Seitenmetadaten locale-bewusst und aus gemeinsam genutzten Seiten-JSON-Einstellungen heraus.

• Media ist der kanonische Name für gemeinsam genutzte hochgeladene Dateien in der gesamten aktiven CMS-Laufzeit.
• Aktive technische Namen verwenden jetzt Media, media_id, media, media_folders und block_media im aktuellen Laufzeitcode, in Requests, Revisionen und Site-Transfer-Paketen.
• Ältere Asset-Namen bleiben nur für Kompatibilitäts-Wrapper, historische Migrationen und die Normalisierung älterer Payloads oder Archive bestehen.
• Admin -> Media behält den Hauptlistentitel Media und den Titel der Listenkarte Media Library.
• In der Medienliste öffnen der Titellink und das Stiftsymbol beide Edit Media: {title} und tragen eine sichere Medien-Rücksprung-URL zur aktuell gefilterten Liste.
• Das Augensymbol bleibt die Aktion für das große Vorschau-Modal aus der Liste.
• Die Detail-Route /webadmin/media/{id} leitet auf /webadmin/media/{id}/edit weiter, damit Medien-Detaillinks auf dem kanonischen Bearbeitungsbildschirm landen.
• Edit Media vereint Vorschau, Dateidetails, Metadaten, Organisation, Verwendung und Danger-Zone-Verwaltung auf einem Bildschirm.
• Copy public URL befindet sich jetzt im Bereich File Details des Bearbeitungsbildschirms statt in der Aktionsspalte der Liste.
• Das Löschen folgt dem standardmäßigen Muster aus Admin-Modal plus Danger Zone statt Browser-Confirm-Markup.

• Site-Variablen werden relational in site_variables gespeichert.
• Es sind site-bezogene, geordnete Datensätze mit Schlüssel, Label, Wert, Aktivierungsstatus und Sortierreihenfolge.
• Die unterstützte öffentliche Token-Syntax ist exakt {{ site.variable_key }} mit optionalem innerem Leerraum.
• Schlüssel werden zu snake_case in Kleinbuchstaben normalisiert und müssen dem konservativen Muster ^[a-z][a-z0-9_]*$ entsprechen.
• Unbekannte Tokens, deaktivierte Variablen, ungültige Schlüssel und Nicht-Site-Tokens bleiben unverändert.
• Die Ersetzung ist reine Textsubstitution. Sie ist keine allgemeine Template-Engine.
• Es werden keine Bedingungen, Schleifen, Funktionsaufrufe, env-Zugriffe, config-Zugriffe, PHP-Ausführung, verschachtelte Variablen oder beliebige Ausdrücke unterstützt.
• Die Ersetzung erfolgt nur während des gemeinsamen öffentlichen Renderings und der öffentlichen Suchindexierung.
• Admin-Formulare und Admin-Vorschauen behalten den rohen gespeicherten Token-Text.
• Variablenwerte werden als Klartext behandelt. In HTML-fähigen öffentlichen Kontexten werden sie als escapeter Text eingefügt, nicht als ausführbares Markup.

Die Bearbeitung erfolgt über Slots.

Typischer Ablauf:

1. Eine Seite erstellen.
2. Ein Layout zuweisen.
3. Die Slots des Layouts bearbeiten.
4. Blöcke innerhalb dieser Slots hinzufügen und anordnen.

Blöcke können Eltern-Kind-Beziehungen haben, was gruppierte Inhaltsstrukturen ermöglicht, ohne das Modell in undurchsichtige Blobs zu verwandeln.

Blöcke sind die wiederverwendbaren redaktionellen Einheiten des CMS.

• Gemeinsame Daten halten Struktur, Platzierung, Assets und operative Einstellungen.
• Übersetzte Daten halten den nutzerseitigen Text für jede Sprache (Locale).
• Nutzerseitige Inhalte werden nicht in beliebigen JSON-Blobs gespeichert.

System-Navigationsblöcke folgen derselben relationalen Regel. Navbar behält das persistierte sticky-navbar-Handle aus Kompatibilitätsgründen, fungiert jetzt aber als primitiver Container-Block: Er rendert nur nav.wb-navbar plus verschachtelte Kind-Blöcke. Er rendert von sich aus kein Marken-Markup, keine Menülinks, keine Header-Aktionen und keinen erzwungenen Container.

Die Navbar-Komposition ist relational statt JSON-getrieben:

• Navbar besitzt nur die Wrapper-Semantik und eine gemeinsame Position-Einstellung.
• Container besitzt die Breitenbeschränkung. Ältere Container verwenden aus Kompatibilitätsgründen weiterhin standardmäßig den gestapelten Fluss, aber Flow = None macht den Container layout-neutral, sodass Kind-Layout-Blöcke die Komposition steuern.
• Cluster ist das horizontale oder gruppierte Layout-Primitiv. Seine Einstellungen steuern Breite, Ausrichtung, Querachsen-Ausrichtung, Umbruch und Abstand.
• Stack bleibt das vertikale Fluss-Primitiv.
• Navbar Brand besitzt Logo und Markentext.
• Navbar Navigation besitzt die Menüauswahl und rendert die navigation_items der Site mit den WebBlocks-UI-Navbar-Klassen. Auf schmalen Bildschirmen rendert er außerdem einen barrierefreien Burger-Toggle, der dasselbe Menü über das WebBlocks-UI-Dropdown-Verhalten öffnet, während Marke und Header-Aktionen in der Hauptzeile der Navbar bleiben.
• Header Actions, Search Form, Container und andere kompatible Blöcke können bei Bedarf als Kinder innerhalb von Navbar platziert werden.
• Navbar Brand und Navbar Navigation müssen irgendwo innerhalb des Navbar-Vorfahrenbaums liegen, müssen aber keine direkten Kinder des Wurzel-Navbar-Blocks sein.
• Navbar Brand unterstützt die reine Logo-Nutzung, wenn ein Logobild vorhanden ist. Ist der sichtbare Titeltext leer, liefert ein explizites barrierefreies Label oder das aufgelöste Site-Label den sicheren Fallback-Namen.

Empfohlene Komposition:

• Navbar
• Container (Flow: None)
• Cluster (Width: Full, Justify: Between, Align: Center, Wrap: Nowrap)
• Navbar Brand
• Cluster (Justify: End, Align: Center, Wrap: Nowrap)
• Navbar Navigation
• Header Actions

Verwenden Sie Container für die Breite, Cluster für die horizontale Verteilung und Stack für den vertikalen Fluss. Navbar bleibt nur der nav-Wrapper und fügt von sich aus keine CMS-spezifischen Layout-Helfer hinzu.

Das hält die Header-Komposition explizit, wiederverwendbar und an WebBlocks UI ausgerichtet, statt eine rein CMS-eigene Navbar-Designfläche zu duplizieren.

Das hält die Inhaltsverantwortung über Multisite, Lokalisierung, Revisionen und öffentliches Rendering hinweg klar.

Suche V1 ist abgeleitete öffentliche Infrastruktur, keine Website-Logik der Projektebene.

• Die Suche indexiert ausschließlich veröffentlichte öffentliche Seiten.
• Suchzeilen sind nach Site und Sprache (Locale) gescoped.
• Die Suche verwendet Seitenübersetzungen als Quelle der Wahrheit für Titel und öffentliche URL-Metadaten.
• Der Suchinhalt wird aus seiteneigenen veröffentlichten Blöcken plus kompatiblen Shared-Slot-Blöcken aufgebaut, die im Kontext der konsumierenden Seite aufgelöst werden.
• Versteckte Shared-Slot-Quellseiten sind von der öffentlichen Routenauflösung und von eigenständigen Suchergebnissen ausgeschlossen.
• Die erste Version speichert abgeleitete Zeilen in der Datenbanktabelle public_search_index und verwendet konservatives SQL-Matching statt eines externen Suchdienstes.
• Suchzeilen sind abgeleitete Laufzeitdaten und können sicher aus dem CMS-Inhalt neu aufgebaut werden.

Die öffentliche Seitenstruktur wird auf der Seiten- und Slot-Ebene gesteuert.

• Page Layout ist der administrationsseitige Name für die Konfiguration der äußeren Shell auf Seitenebene.
• Page Layouts werden jetzt als verwaltete Datensätze auf Installationsebene unter Admin -> System -> Page Layouts geführt.
• Das gespeicherte Kompatibilitätsfeld bleibt in dieser Phase public_shell, damit bestehende Seitendaten und Handles gültig bleiben.
• default ist die standardmäßige öffentliche Shell.
• docs ist die dokumentationsorientierte Shell für Layouts mit Header-, Sidebar- und Hauptinhaltsbereichen.
• Die eingebauten Default Layout und Docs Layout sind vorinstallierte System-Layouts mit den stabilen Handles default und docs.
• Seiten speichern das ausgewählte Page-Layout-Handle, nicht einen separat aufgelösten Shell-Modus.
• Das Page Layout besitzt jetzt optionale validierte öffentliche body_class-Tokens.
• Page Layout Slots sind relationale Datensätze auf Installationsebene, die an ein Page Layout angehängt sind und die Slot-Reihenfolge sowie Wrapper-Metadaten definieren.
• Slot Types sind der wiederverwendbare Katalog für die Zuweisung von Page Layout Slots.
• Das Rendering zur Laufzeit löst das gespeicherte Handle, sofern verfügbar, in einen Page-Layout-Datensatz auf und ermittelt anschließend Body-Klassen und Slot-Wrapper aus dessen verwalteten Page Layout Slots.
• Die Body Class ist für layoutspezifisches CSS auf dem öffentlichen <body> gedacht, während die Wrapper-IDs und -Klassen der Page Layout Slots CSS-Ankerpunkte auf Bereichsebene innerhalb dieses Layouts bereitstellen.
• Das Sticky-Verhalten der öffentlichen Navbar stammt aus dem mitgelieferten wb-navbar-Primitiv. Wenn ein öffentlicher Standard-Header-Slot nur einen Navbar-Block enthält, hebt das CMS den Slot-Wrapper zur nav.wb-navbar-Wurzel an, damit das Sticky-Verhalten nicht durch einen zusätzlichen Header-Wrapper eingeschränkt wird.
• Die Seitenbearbeitung vergleicht die verwalteten Layout Slots des ausgewählten Page Layouts mit den aktuellen Page Slots der Seite.
• Fehlende Layout Slots können über Add Missing Layout Slots explizit hinzugefügt werden.
• Überzählige Page Slots werden aus Sicherheitsgründen erhalten und gemeldet statt gelöscht.
• Neue Seiten verwenden aktive verwaltete Page Layout Slots aus dem ausgewählten Page Layout, bevor sie auf Legacy-Slot-Arrays zurückfallen.
• Das Ändern des Page Layouts bei einem normalen Speichern verändert bestehende Page Slots nicht automatisch.
• Benutzerdefinierte Page Layouts in V1 können eigene Handles verwenden, nutzen aus Kompatibilitätsgründen aber weiterhin konservativ das bestehende default- oder docs-Shell-Verhalten.
• Der Slot-Name bestimmt die semantische öffentliche Wrapper-Rolle für diesen Bereich.
• Slot-Wrapper werden, sofern verfügbar, automatisch aus verwalteten Page Layout Slots aufgelöst, mit Legacy-Fallback-Definitionen für eingebaute Layouts. Unbekannte Slots verwenden den sicheren Standard-div-Wrapper.
• Erweitertes vertrauenswürdiges Layout-HTML existiert nur für strukturelles Markup in unmittelbarer Wrapper-Nähe. Es ist keine allgemeine Skripting-Oberfläche und darf nicht für Skripte verwendet werden.
• Header-Slots sind standardmäßig layoutneutral und erzwingen kein wb-stack um ihre Blockbäume.
• Main-Slots können den gestapelten Rhythmus weiterhin über ihr Shell-Partial besitzen, wenn diese Darstellung beabsichtigt ist.
• Der Abstand zwischen Header und Main gehört zum öffentlichen Shell-Wrapper, nicht zur Navbar oder zu anderen einzelnen Header-Blöcken. Die Header- und Main-Wrapper der Default-Shell besitzen diesen Rhythmus, sodass der erste Inhaltsblock keine Ad-hoc-Abstände nach oben benötigt.
• Das Sticky-Verhalten der Navbar sollte weiterhin dem mitgelieferten WebBlocks-UI-Vertrag .wb-navbar gehören. Page Layout und Header-Slot-Wrapper besitzen die Struktur auf Seitenebene, aber das CMS sollte keine parallele Sticky-Klasse für die Navbar injizieren.
• Blöcke rendern Inhalte innerhalb dieser Slot-Wrapper und dürfen die äußere Seiten-Shell nicht besitzen.
• Die Page-Layout-Validierung erlaubt vertrauenswürdige Wrapper-Snippets für strukturelle Lücken, lehnt aber Skripte, Event-Attribute, javascript:-URLs sowie iframe-, object- und embed-Inhalte ab.

Verwenden Sie für Seiten im Dokumentationsstil das Page Layout, anstatt die Layout-Verantwortung in einzelne Inhaltsblöcke zu verlagern. Das übliche Rezept ist Page Layout = Docs Layout mit den Slots Header, Sidebar und Main, damit die Shell sie automatisch auf die Navbar-, Sidebar- und Main-Wrapper der Dokumentation abbilden kann.

In V1 besitzt das Page Layout die Wahl der äußeren öffentlichen Shell, Slot-Namen besitzen die Semantik der Bereichs-Wrapper, und Blöcke besitzen den Inhalt innerhalb dieser Wrapper.

• Öffentliche Metadaten werden aus dem Kontext der aktuellen Site und der aktuellen Seitenübersetzung aufgelöst, nicht aus der Project Identity oder aus bearbeitbaren Legacy-Einstellungen für Anwendungsname oder Slogan.
• Öffentliche Seitentitel folgen standardmäßig dem Muster Site Label · Page Label.
• Die Rangfolge für das Site-Label lautet: Site display_name, Site seo_title, Site name, dann ein sicherer CMS-Fallback.
• Die Rangfolge für das Seiten-Label lautet: Seitenübersetzung seo_title, dann der Titel der Seitenübersetzung.
• Die Rangfolge für die Beschreibung lautet: Seitenübersetzung seo_description, Site seo_description, andernfalls kein Description-Tag.
• Die Rangfolge für Keywords lautet: Seitenübersetzung seo_keywords, Site seo_keywords, andernfalls kein Keywords-Tag.
• Die Rangfolge für den Open-Graph-Titel lautet: Seitenübersetzung og_title, andernfalls dasselbe Site-zuerst-Muster des öffentlichen Titels.
• Die Rangfolge für die Open-Graph-Beschreibung lautet: Seitenübersetzung og_description, Seitenübersetzung seo_description, Site seo_description.
• Die Rangfolge für das Open-Graph-Bild lautet: Seitenübersetzung og_image_media_id, Site social_image_media_id, andernfalls kein og:image-Tag.
• Das Favicon-Medium der Site ist unverändert und bleibt in dieser Phase ausschließlich auf Site-Ebene.
• Multisite-Metadaten bleiben über die aufgelöste öffentliche Site host-bewusst; die primäre Site wird nicht blind verwendet, wenn eine andere Site zum aktuellen Host passt.

• Die öffentliche Suche bleibt auf die aufgelöste Site und Sprache (Locale) beschränkt.
• Der Text des Suchmodals kann das aufgelöste Site-Label enthalten, damit Benutzer sehen können, welche Site durchsucht wird.
• Die Texte der öffentlichen Suche verwenden die Site Identity, nicht die Project Identity.

Shared Slots sind eine Ebene für die Inhaltszuständigkeit von Slots, die unter dem bestehenden Page-Layout-Modell liegt.

• Das Page Layout besitzt weiterhin, welche Slots verfügbar sind.
• Seiten-Shell plus Slot-Name besitzen weiterhin die öffentlichen Wrapper für jeden Slot.
• Die Quelle jedes Page Slots kann page, shared_slot oder disabled sein.
• page bedeutet, dass der Slot Blöcke verwendet, die direkt der Seite gehören; das ist das bisherige Verhalten.
• shared_slot bedeutet, dass der Slot auf einen site-gebundenen, wiederverwendbaren Shared-Slot-Blockbaum verweist, der zur öffentlichen Laufzeit dynamisch gerendert wird.
• disabled bedeutet, dass der Slot-Wrapper weiterhin existiert, darin aber keine Blöcke gerendert werden.
• Shared Slots sind site-gebundene, wiederverwendbare Slot-Blockbäume, keine kopiebasierten Vorlagen.
• Shared-Slot-Referenzen sind nur innerhalb derselben Site gültig. Site-übergreifende Seitenoperationen müssen auf einen kompatiblen Shared Slot der Ziel-Site umgemappt werden oder je nach Operation und expliziter Benutzerwahl auf ein sicheres blockiertes oder deaktiviertes Ergebnis zurückfallen.
• Shared Slots besitzen weder Seiten-Shells noch Slot-Wrapper. Die Seiten-Shell besitzt weiterhin die äußere Shell, und der konsumierende Page Slot besitzt weiterhin den Wrapper für header, main, sidebar oder andere Slot-Bereiche.
• Ein gültiger Shared Slot steuert nur den Blockbaum bei, der innerhalb dieses bestehenden Page-Slot-Wrappers gerendert wird.
• Das öffentliche Rendering von Shared Slots ist konservativ:
• Site-übergreifende Shared-Slot-Referenzen rendern nichts.
• Die Shared-Slot-Verwaltungsansichten beschreiben die optionale Einschränkung SharedSlot.public_shell als Page Layout, der gespeicherte Feldname bleibt in diesem Release aber aus Gründen der Abwärtskompatibilität public_shell.
• Wenn SharedSlot.public_shell gesetzt ist, muss es exakt mit dem Page-Layout-Handle der konsumierenden Seite übereinstimmen.
• Wenn SharedSlot.slot_name gesetzt ist, muss es mit dem Slot-Namen des konsumierenden Page Slots übereinstimmen.
• Null oder leere Werte für public_shell und slot_name wirken als generische Übereinstimmung.
• Ein benutzerdefiniertes Page-Layout-Handle, das auf shell_type = docs abgebildet wird, passt in V1 nicht automatisch zu einem auf docs eingeschränkten Shared Slot.

Der aktuelle Umfang umfasst jetzt Grundlagen, öffentliches Rendering, site-gebundene Verwaltung im Adminbereich, die Zuweisung von Page-Slot-Quellen und Unterstützung für Site-Portabilität von Shared Slots.

• Shared Slots haben im Site-Content-Bereich des Adminbereichs eine eigene Übersichtsliste und eigene Metadaten-Formulare.
• Shared-Slot-Blockbäume werden über einen dedizierten Shared-Slot-Blockeditor bearbeitet, der das aktuelle Block-Autorenmodell wiederverwendet, anstatt Inhalte in konsumierende Page Slots zu kopieren.
• Shared-Slot-Blöcke bleiben echte blocks-Datensätze, die über shared_slot_blocks verbunden sind; übersetzte Texte verbleiben in den bestehenden Übersetzungstabellen.
• Das Löschen eines Shared Slots ist blockiert, solange noch irgendein Page Slot darauf verweist.
• Der Seiteneditor bietet jetzt pro Slot eine Quellenauswahl mit drei unterstützten Modi:
• Page Content: page_slots.source_type = page und shared_slot_id = null.
• Shared Slot: page_slots.source_type = shared_slot und shared_slot_id zeigt auf einen kompatiblen aktiven Shared Slot derselben Site.
• Disabled: page_slots.source_type = disabled und shared_slot_id = null.
• Das Ändern einer Slot-Quelle löscht oder trennt den bestehenden seiteneigenen Blockbaum für diesen Slot nicht. Wenn ein Editor einen Slot auf shared_slot oder disabled umstellt, bleiben die seiteneigenen Blöcke verbunden, sodass ein Zurückschalten auf Page Content den vorherigen seitenspezifischen Inhalt wiederherstellt.
• Das Hinzufügen fehlender Layout Slots folgt demselben Sicherheitsprinzip: Es erstellt nur neue Page Slots und verändert weder bestehende Shared-Slot-gestützte Slots noch deaktivierte Slots oder seiteneigene Blockbäume.
• Der Seiteneditor filtert die Auswahl an Shared Slots konservativ. Nur aktive Shared Slots derselben Site erscheinen, und die optionalen Shared-Slot-Einschränkungen public_shell und slot_name müssen zur konsumierenden Seiten-Shell und zum Slot-Namen passen.
• Shared-Slot-Verwaltungsformulare beschriften diese optionale public_shell-Einschränkung jetzt als Page Layout, damit der benutzerseitige Begriff mit dem Seiteneditor und den Verwaltungsansichten für Page Layouts übereinstimmt.
• Site-Export/-Import und das Klonen übertragen weiterhin public_shell-Handles auf Seitenebene als Teil der Seitenkonfiguration. Page-Layout-Definitionen auf Installationsebene bleiben in V1 lokal zur Installation; Ziel-Installationen sollten daher alle benutzerdefinierten Handles definieren, die sie ohne Fallback rendern möchten.
• Auch Page-Layout-Slot-Definitionen auf Installationsebene bleiben in V1 lokal zur Installation.
• Die öffentlichen Rendering-Schutzmechanismen zur Laufzeit bleiben auch nach der Validierung beim Schreiben bestehen, sodass ungültige, veraltete, site-übergreifende, inaktive oder inkompatible Zuweisungen öffentlich weiterhin keine geteilten Inhalte rendern.
• Shared Slots nehmen jetzt an Site-Export/-Import und am Site-Klonen teil. Ihre Metadaten, die Blockbäume der versteckten Quellseite, Übersetzungen, verschachtelte Reihenfolgen und Medienreferenzen werden als vollwertiger Site-Content übertragen. Konsumierende Page Slots behalten beim Export ihre shared_slot-Referenzen über das Shared-Slot-Handle und werden beim Import und Klonen auf Shared Slots der Ziel-Site umgemappt.
• Versteckte Shared-Slot-Quellseiten bleiben intern. Sie sind von normalen Seiten-Export-Payloads, gewöhnlichen Seitenlisten und dem öffentlichen Routing ausgeschlossen, auch wenn ihre Blockdatensätze weiterhin den Shared-Slot-Editor und die Portabilitätsabläufe stützen.
• Shared Slots haben jetzt eine eigene Revisionshistorie und einen eigenen Wiederherstellungsablauf, der bewusst von Seitenrevisionen getrennt ist.
• Shared-Slot-Revisionen erfassen die Shared-Slot-Metadaten sowie den wiederverwendbaren Shared-Slot-Blockbaum hinter der versteckten internen Quellseite.
• Das Wiederherstellen einer Shared-Slot-Revision stellt den Shared Slot an Ort und Stelle wieder her. Die Shared-Slot-ID bleibt stabil, bestehende page_slots.shared_slot_id-Referenzen bleiben intakt, und der wiederhergestellte Inhalt wirkt sich sofort auf jede Seite aus, die auf diesen Shared Slot verweist.
• Shared-Slot-Revisionen behandeln Seitenrevisionen nicht als maßgeblich für Shared-Slot-Inhalte, und Seitenrevisionen geben nicht vor, Shared-Slot-Blockbäume zu erfassen.

Die Workflow-Veröffentlichung von Seiten und die Veröffentlichung von Blöcken sind standardmäßig getrennt. Das Veröffentlichen eines Seitendatensatzes macht die Seite routbar, wenn ihre Locale-/Pfadregeln passen, veröffentlicht aber nicht stillschweigend Entwurfs- oder In-Review-Blöcke innerhalb dieser Seite. So können Editoren und Prüfer die Seiten-Shell veröffentlichen und ausgewählte Blöcke für eine spätere Prüfung zurückhalten.

Wenn ein Benutzer sich explizit dafür entscheidet, seiteneigene Blöcke einzubeziehen, veröffentlicht WebBlocks CMS nur Blöcke, die den nicht geteilten Page Slots der Seite gehören. Verschachtelte Kindblöcke unter diesen seiteneigenen Slots werden einbezogen. Shared-Slot-gestützte Slots sind ausgeschlossen; ihre wiederverwendbaren Blockbäume müssen über Shared-Slot-spezifische Workflows geprüft und veröffentlicht werden.

Die Internal Content API folgt derselben Regel. POST /webadmin/api/pages/{page}/publish verwendet standardmäßig include_page_owned_blocks: false, erfordert content.publish und schließt Shared Slots aus. KI-/Operator-Tools dürfen include_page_owned_blocks: true nur mit expliziter Zustimmung des Benutzers aktivieren.

• Die Site Promotion arbeitet auf site-eigenem Content, nicht auf der gesamten Installation.
• Sie kann sichere Site-Identity-Felder, Sprachzuweisungen (Locales), Site-Variablen, Seiten, Seitenübersetzungen, Slots, Blöcke, Shared Slots, Navigation, Seiten-Assets und optionale Paketdatei-Assets aktualisieren.
• Sie bewahrt Daten auf Installationsebene und Live-Laufzeitdaten wie Benutzer, Sessions, Backups, Update-Historie, Kontaktformular-Einsendungen, Besucherberichte, Domains, Umgebungseinstellungen und Secrets.
• Sie behandelt public_search_index nicht als portablen Content. Suchzeilen werden nach dem Anwenden aus dem promoteten Content neu aufgebaut.
• Sie ist ein kontrollierter Paket-Workflow, keine rohe Datenbankreplikation.

Der WebBlocks-CMS-Kern enthält wiederverwendbare CMS-Funktionalität.

• Halten Sie installationsspezifischen Code, der CMS-Updates überstehen muss, in project/.
• Halten Sie site-spezifische Befehle, Views, Routen, Konfiguration, Import-Helfer und Migrations-Workflows aus dem Kern heraus, wenn sie keine wiederverwendbaren Produktfunktionen sind.
• Behandeln Sie project/ als update-sichere Erweiterungsgrenze für eine Installation.
• Halten Sie wiederverwendbares Produktverhalten wie Blöcke, Layouts, Admin-UI, öffentliche Renderer, Workflow, Backup/Restore, Export/Import und generische Unterstützung der Projektschicht im Kern.
• Halten Sie Site-Migrations-/Import-Helfer und installationsspezifische Content-Sync-Werkzeuge in project/.
• Schnelle Website-Migrationsbrücken können in project/ liegen, wenn sie bewusst temporär und website-spezifisch sind. Der WebBlocks-UI-Importer für die verbleibende Dokumentation ist ein Beispiel: Er speichert abgerufene <main>-Fragmente der Dokumentation als vertrauenswürdiges HTML in Projekt-Payload-Form, ohne dem CMS-Kern etwas über diese Website beizubringen.
• Eine solche Brücke sollte bestehenden kuratierten CMS-Content bewahren, das Shell- oder Navigationsverhalten beim CMS belassen und die temporäre Grenze für vertrauenswürdiges HTML explizit machen, damit eine spätere Überführung in vollwertige Blöcke möglich bleibt.
• Kern-Release-Pakete liefern keine project/-Inhalte aus.

Siehe ../DEVELOPMENT.md für den vollständigen Entwicklungs- und Release-Workflow.