WebBlocks CMS · Block-UI-Renderer-Vertrag

Phase 1 definiert den beabsichtigten öffentlichen Rendering-Vertrag zwischen CMS-Layouts, Slots und Blocktypen und den ausgelieferten WebBlocks-UI-Primitiven, die das öffentliche Layout bereits lädt. Diese Phase ist reine Dokumentation. Sie schreibt die Renderer noch nicht um.

Verifiziert gegen die tatsächlich ausgelieferten Assets, die das CMS verwendet:

CSS: https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-ui.css
Icons CSS: https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-icons.css
JS: https://cdn.jsdelivr.net/gh/fklavyenet/webblocks-ui@v2.7.12/packages/webblocks/dist/webblocks-ui.js

Bestätigte Primitive und Muster:

wb-content-shell
wb-content-header
wb-content-body
wb-content-footer
wb-promo
wb-callout
wb-link-list
wb-stat
wb-gallery
wb-alert
wb-rich-text
wb-rich-text-readable
wb-rich-text-compact
wb-rich-text-loose
wb-btn
wb-grid
wb-grid-2
wb-grid-3
wb-grid-4
wb-stack
wb-gap-1
wb-gap-2
wb-gap-3
wb-gap-4
wb-gap-6
wb-gap-8

Vorerst fehlende Primitive und UI-Lücken:

wb-prose — in den ausgelieferten WebBlocks-UI-Assets NICHT GEFUNDEN. Behandeln Sie dies als UI-Lücke und verlassen Sie sich für die Layout- oder Renderer-Ausrichtung in Phase 2 nicht darauf.
wb-promo-muted — in den ausgelieferten WebBlocks-UI-Assets NICHT GEFUNDEN.
wb-promo-accent — in den ausgelieferten WebBlocks-UI-Assets NICHT GEFUNDEN.
wb-cluster-3 — in den ausgelieferten WebBlocks-UI-Assets NICHT GEFUNDEN.

Verifizierte ausgelieferte JS-Hooks, die für das aktuelle öffentliche Rendering relevant sind:

data-wb-toggle="dropdown"
data-wb-toggle="modal"
data-wb-gallery-target
#wb-overlay-root

Öffentliche Seiten verwenden jetzt explizite Layout-Kompositionsmodi:

stack ist der Standardmodus.
sidebar wird verwendet, wenn die Seite einen befüllten Sidebar-Slot hat.
content ist zukünftigen Dokumentations-/Redaktionsseiten mit expliziten Metadaten vorbehalten und darf nicht aus URL oder Titel geraten werden.
wb-content-shell ist kein universeller Wrapper und sollte nur erscheinen, wenn die Seitenmetadaten eine Content-Shell-Darstellung ausdrücklich unterstützen.

CMS-Block	WebBlocks-UI-Primitiv/Muster	Status	Priorität	Nächster Schritt
öffentliches Layout	wb-public-body, wb-public-main, wb-container	akzeptabel	P0 Shell/Layout	die Shell stabil halten und slot-spezifisches Chrome in Richtung dokumentierter Primitive verlagern
Header-Slot	wb-section, wb-container, Nav-/Listen-Primitive	schwach	P0 Shell/Layout	individuelles Header-Chrome an den dokumentierten Shell-Regeln ausrichten
Main-Slot	wb-public-main, wb-container, wb-content-shell	akzeptabel	P0 Shell/Layout	wb-content-shell dort einsetzen, wo der Inhalt wie Artikel-/Dokumentationsinhalt wirkt
Sidebar-Slot	wb-grid, wb-stack, optionales wb-content-shell-Aside	schwach	P0 Shell/Layout	generische Sidebars nicht länger wie Pseudo-App-Sidebars behandeln
Footer-Slot	wb-section, wb-container, wb-grid, Linkliste-/Nav-Primitive	akzeptabel	P0 Shell/Layout	den Footer auf den ausgelieferten Layout-Primitiven halten und zusätzliche eigene Klassen vermeiden
heading	Altbestand, entfernt	eingestellt	P0 entfernt	nicht wieder einführen; header ist der kanonische Überschriften-/Titelblock
text	Fließtext im wb-stack-Rhythmus	akzeptabel	P2 Inhaltsqualität	die Ausgabe einfach halten und maßgeschneiderte Typografie-Wrapper vermeiden
rich-text	wb-rich-text wb-rich-text-readable	akzeptabel	P2 Inhaltsqualität	sicheren Fließtext auf das ausgelieferte Rich-Text-Primitiv beschränkt halten
html	vertrauenswürdiges rohes HTML im öffentlichen Block-Wrapper	akzeptabel	P3 später/individuell	auf vertrauenswürdige redaktionelle/administrative Nutzung beschränkt halten und mitgelieferte Overlay-Inhalte in die gemeinsame Seiten-Overlay-Root heben
section	wb-section, optionales wb-promo	akzeptabel	P1 öffentliches Marketing/Dokumentation	die Standard-Sektion stabil halten und Promo-Semantik expliziten Varianten vorbehalten
columns	wb-grid, wb-grid-2, wb-grid-3, wb-grid-4, wb-link-list	akzeptabel	P1 öffentliches Marketing/Dokumentation	elterngesteuerte Varianten explizit halten und keine erzwungenen Wrapper-Karten wieder einführen
column_item	einfache Zelle, wb-card, wb-stat oder Linklisten-Eintrag	akzeptabel	P1 öffentliches Marketing/Dokumentation	das Rendering der Einträge weiterhin über das columns.variant-Mapping des Elternblocks steuern
callout	wb-alert, optionales wb-callout	akzeptabel	P2 Inhaltsqualität	das Varianten-Mapping erweitern, falls ein ausgeliefertes Sidebar-/Hilfe-Callout existiert
quote	semantisches blockquote, optional gerahmte Karte	akzeptabel	P2 Inhaltsqualität	die Rahmung bedingt statt immer kartenartig gestalten
faq	einfache Frage-/Antwort-Karte	akzeptabel	P3 individuell/Fallback	die stabile Einzelkarten-Darstellung beibehalten und gruppierte Aufklapp-Strukturen den Akkordeon-Blöcken überlassen
tabs	interaktives Tabs-Muster	schwach	P2 Inhaltsqualität	zurückstellen, bis ein echtes ausgeliefertes Tabs-Muster existiert
button	wb-btn-Varianten	schwach	P1 öffentliches Marketing/Dokumentation	alle unterstützten CMS-Varianten abbilden und eine Button-Gruppen-Ausrichtung ergänzen
image	semantisches figure, img, figcaption	schwach	P2 Inhaltsqualität	das Linkverhalten respektieren und Medienrahmung nur bei Bedarf hinzufügen
gallery	wb-gallery plus Overlay-Root-Modal	akzeptabel	P1 öffentliches Marketing/Dokumentation	weiterhin die ausgelieferten Galerie-Hooks und die zentrale Overlay-Root verwenden und den Einleitungstext außerhalb des Galerie-Blocks selbst halten
download	wb-btn oder Karte-mit-Button-CTA	akzeptabel	P2 Inhaltsqualität	explizite Karten-/Download-Varianten später ergänzen
navigation-auto	Nav-/Listen-Primitive, optionales wb-link-list	akzeptabel	P1 öffentliches Marketing/Dokumentation	einfache Menüs einfach halten und Dokumentations-Sidebars echten Dokumentations-Shells vorbehalten
menu	Legacy-Alias von navigation-auto	akzeptabel	P3 später/individuell	nur für migrierte Daten behalten
contact_form	Formular-Primitive, wb-btn, wb-alert	akzeptabel	P1 öffentliches Marketing/Dokumentation	strukturierte Editor-Felder beibehalten und rohe HTML-Formulare vermeiden
hero	wb-promo-Marketing-Shell	akzeptabel	P1 öffentliches Marketing/Dokumentation	den Hero erstklassig, übersetzt und über untergeordnete Button-Blöcke aktionsgetrieben halten
card-grid	Kartenraster-Muster	schwach	P1 öffentliches Marketing/Dokumentation	das aktuelle strukturierte Kartenraster stabil halten und eine erstklassige Modellierung später erneut prüfen
showcase-list	Showcase-/Galerie-Muster	schwach	P3 später/individuell	entweder als erstklassigen Showcase-Block formalisieren oder individuell belassen
contact-info	Linkliste / Kontakt-Meta-Karte	schwach	P2 Inhaltsqualität	nur dann zu erstklassig befördern, wenn Editoren es über die Seed-Seiten hinaus benötigen
code	Codeblock-Muster	fehlend	P2 Inhaltsqualität	erstklassige Renderer-/Admin-Unterstützung ergänzen oder den Fallback bewusst beibehalten
list	Listen-Primitiv	akzeptabel	P1 öffentliches Marketing/Dokumentation	den dedizierten zeilenbasierten Editor behalten und die Kompatibilität mit Legacy-Einstellungen im Fallback-Stil bewahren
table	wb-table-Muster	akzeptabel	P1 öffentliches Marketing/Dokumentation	den dedizierten zeilenbasierten Editor behalten und die Legacy-Einstellungszeilen im Fallback-Stil bewahren
accordion	semantisches Disclosure-Muster	akzeptabel	P1 öffentliches Marketing/Dokumentation	den erstklassigen semantischen -Renderer mit Kindblöcken als Einträgen beibehalten
feature-grid	delegiertes columns.variant = cards-Muster	akzeptabel	P1 öffentliches Marketing/Dokumentation	als Kompatibilitäts-Alias veröffentlicht lassen, für neue strukturierte Inhalte aber columns bevorzugen
stats / metric-card	delegiertes columns.variant = stats-Muster	schwach	P1 öffentliches Marketing/Dokumentation	Aliase ehrlich halten und echte statistik-spezifische Verträge nur ergänzen, wenn sie produktseitig verantwortet werden
logo-cloud	Logo-Raster / Markenleiste	schwach	P1 öffentliches Marketing/Dokumentation	strukturierte Medienverarbeitung ergänzen, falls es produktisiert bleibt
testimonial	delegiertes Zitat-Testimonial-Muster	schwach	P2 Inhaltsqualität	das Alias-Verhalten ehrlich halten, solange kein eigenständiger Testimonial-Vertrag produktseitig verantwortet wird
timeline	Timeline-Muster	schwach	P2 Inhaltsqualität	nur befördern, wenn Timeline-Inhalte ein echter wiederkehrender Anwendungsfall sind
pricing	Preiskarten-/Preisraster-Muster	schwach	P1 öffentliches Marketing/Dokumentation	nur mit strukturierten Plänen/Features erstklassig machen
toc	Inhaltsverzeichnis-Navigation	akzeptabel	P1 öffentliches Marketing/Dokumentation	die Sammlung des seiteninternen Inhaltsverzeichnisses ausschließlich auf explizit verankerte header-Blöcke beschränken
breadcrumb	Breadcrumb-Navigation	fehlend	P2 Inhaltsqualität	zurückstellen, bis die öffentliche Seiten-Shell sie wirklich braucht und ein ausgeliefertes Muster bestätigt ist
cookie-notice	gemeinsames Datenschutz-Banner-/Modal-Muster	fehlend	P3 später/individuell	die Einwilligungs-UI im öffentlichen Layout statt in Block-Renderern halten

Das öffentliche Layout besitzt die seitenweite Shell und sollte den Basis-Vertrag <body class="wb-public-body"> beibehalten.
Page Layout ist der editorseitige Name für den äußeren öffentlichen Shell-Modus.
Das gespeicherte Kompatibilitätsfeld bleibt in dieser Phase public_shell, aber Page Layouts sind jetzt auf Installationsebene verwaltete Datensätze im Admin-Bereich.
Das Page Layout darf dieser Basis-Body-Klasse validierte Body-Klassen wie layout-default oder layout-docs hinzufügen.
Wichtige Seitenregionen sollten zuerst aus den ausgelieferten WebBlocks-UI-Layout-Primitiven aufgebaut werden: wb-public-main, wb-container, wb-section, wb-stack, wb-grid.
wb-content-shell, wb-content-header, wb-content-body und wb-content-footer gehören in den Hauptinhaltsbereich, wenn die Seite wie Artikel-, Anleitungs-, Dokumentations- oder Redaktionsinhalt wirkt. Sie sind nicht das seitenweite Header- oder Footer-Chrome der Site.
#wb-overlay-root ist der einzige gemeinsame Einhängepunkt für öffentliche Overlays wie den Galerie-Viewer, das öffentliche Suchmodal und das Cookie-Einstellungsmodal.
Öffentliche Layouts besitzen diesen Wrapper; Blöcke, Partials und vertrauenswürdiges HTML dürfen Overlay-Kinder beisteuern, dürfen aber keine konkurrierenden Overlay-Root-Container rendern.
Vertrauenswürdiges importiertes HTML, das ausgelieferte WebBlocks-UI-Trigger-Hooks verwendet, muss den Trigger-zu-Ziel-Vertrag bewahren. Wenn ein Trigger innerhalb importierter Hauptinhalte auf ein Modal, einen Drawer, ein Popover oder einen Galerie-Viewer außerhalb von <main> zeigt, muss der Extraktor das referenzierte Ziel in die gemeinsame #wb-overlay-root heben, statt es zu verwerfen.
Wenn das CMS eine gemeinsame Dialogebene unter #wb-overlay-root vorab rendert, muss diese Ebene sichtbar bleiben, damit WebBlocks UI v2.7.12 vertrauenswürdige Modal- und Galerie-Ziele hinein portalisieren kann, ohne sie in einem verborgenen Vorfahren zu belassen.

card besitzt article.wb-card als Renderer-Wurzel mit data-wb-public-block-type="card".
card_header besitzt div.wb-card-header mit data-wb-public-block-type="card-header".
card_body besitzt div.wb-card-body mit data-wb-public-block-type="card-body".
card_footer besitzt div.wb-card-footer mit data-wb-public-block-type="card-footer".
Kartenregionen sollten ihre eigenen Wurzeln direkt rendern und dürfen keine zusätzlichen generischen öffentlichen Wrapper erhalten.
Der normale Karten-Vertrag ist komponierbarer Kind-Inhalt über diese drei Regionen, kein eingebauter Promo- oder Medien-Renderer.
Ältere gespeicherte Kartenzeilen dürfen nur dann noch einen minimalen Fallback-Renderer verwenden, wenn die Karte keine Kartenregion-Kinder hat.
wb-sidebar ist einer echten Dokumentations-/App-Navigations-Shell vorbehalten. Generische Marketing- oder Redaktions-Sidebars sollten gewöhnlicher aside-Inhalt bleiben, komponiert aus wb-grid, wb-stack, Karten, Callouts und Linklisten.

Slot-Wrapper sind deterministisches Laufzeitverhalten, keine frei gestaltbaren redaktionellen Einstellungen auf Seitenebene.
Der Seiten-Layout-Handle wird, sofern verfügbar, zuerst zu einem verwalteten Page-Layout-Datensatz aufgelöst, und die verwalteten Page Layout Slots dieses Datensatzes werden dann verwendet, um Slot-Wrapper-Element, Klassen, Ids und vertrauenswürdige strukturelle Snippets aufzulösen.
Der Edit-Page-Vergleich und Add Missing Layout Slots ändern die Seitenstruktur nur durch das Anlegen fehlender Page Slots; sie ändern nicht die Eigentümerschaft öffentlicher Wrapper.
Die vertrauenswürdigen HTML-Felder der Page Layout Slots existieren ausschließlich für wrapper-nahe Layoutstruktur. Sie sind keine Skript-Oberfläche, und die Blocks besitzen weiterhin die Content-Roots, die innerhalb des Slot-Wrappers gerendert werden.
Wenn ein öffentlicher Standard-Header-Slot nur einen Navbar-Block enthält, hebt das CMS den Slot-Wrapper zum nav.wb-navbar-Root an, damit das Sticky-Verhalten der WebBlocks UI nicht durch eine niedrige übergeordnete Header-Box eingeschränkt wird.
wb-navbar--static bleibt die Opt-out-Klasse für nicht-sticky öffentliche Navbar-Blocks.
default ordnet header, main, sidebar und footer semantischen Wrappern zu und fällt bei unbekannten Slots auf div zurück.
docs ordnet header dem Docs-Navbar-Wrapper, sidebar dem Docs-Sidebar-Wrapper und main dem Docs-Main-Wrapper zu, während wb-dashboard-shell im Besitz der Seite bleibt.
Die eingebauten Layouts default und docs behalten verwaltete Fallback-Definitionen, damit das Rendering vor oder ohne relationale Slot-Zeilen stabil bleibt.
Blocks werden innerhalb des aufgelösten Slot-Wrappers gerendert und besitzen kein Page-Shell-Markup.
Das Sticky-Navbar-Verhalten gehört zu .wb-navbar. Das CMS sollte dem Slot-Wrapper oder der Navbar-Block-Ausgabe keine zweite navbar-spezifische Sticky-Klasse hinzufügen.
Wenn ein Seiten-Slot source_type = shared_slot verwendet, liefert der Shared Slot nur den inneren Block-Baum. Er darf keine eigene Page-Shell und keinen eigenen Slot-Wrapper rendern.
Die Shared-Slot-Kompatibilität wird vor dem Rendering geprüft: Der Site-Scope muss übereinstimmen, das optionale public_shell muss exakt dem Layout-Handle der konsumierenden Seite entsprechen, und das optionale slot_name muss dem konsumierenden Seiten-Slot entsprechen.
Generische öffentliche Block-Wrapper müssen nicht-semantisch bleiben und dürfen nicht für Layout-/Root-besitzende Blocks verwendet werden.
Die Page-Shell besitzt die äußere Hülle, Slot-Wrapper besitzen den Regions-Wrapper, und Root-besitzende Blocks besitzen ihr eigenes echtes öffentliches Root-Element.
Root-besitzende Blocks müssen data-wb-public-block-type auf ihrem eigenen Renderer-Root platzieren, statt einen zusätzlichen äußeren wb-public-block-Wrapper zu erhalten.

Vorgesehene Zuordnung: header-Region, aufgebaut aus wb-section und wb-container mit den mitgelieferten Nav-/Listen-Primitiven darin.
Verwenden Sie wb-stack oder wb-grid für den internen Rhythmus, je nachdem, ob der Header als gestapeltes Banner oder als horizontale Navigationsleiste gelesen wird.
Primäre oder rechtliche Navigation kann über navigation-auto oder menu gerendert werden, aber der Slot sollte nicht verlangen, dass Block-Renderer eigenes, nur für den Header bestimmtes HTML ausgeben.
Die aktuelle Implementierung ist schwach, weil der Header-Slot mehrere eigene wb-public-*-Chrome-Klassen besitzt. Phase 2A behält die bestehende wb-section- und wb-container-Hülle unverändert bei und verschiebt jede sichere Reduzierung des eigenen Header-Chromes auf einen späteren Durchgang.

Vorgesehene Zuordnung: <main class="wb-public-main"> ist die primäre Inhaltsregion.
Standard-Hülle: wb-public-main > .wb-container > .wb-stack für gewöhnliche Block-Stapel.
Redaktions-/Docs-Hülle: wb-public-main > .wb-container > .wb-content-shell mit optionalen Abschnitten wb-content-header, wb-content-body und wb-content-footer.
Verschachteltes Block-Layout sollte wb-stack, wb-stack-, wb-gap-, wb-grid und wb-grid-* vor jeder eigenen Wrapper-Klasse verwenden.
Die aktuelle Implementierung ist akzeptabel, weil sie dem Main-Slot bereits einen stabilen öffentlichen Wrapper und Block-Rhythmus gibt. Phase 2B fügt explizite Layout-Modi hinzu, sodass wb-content-shell reserviert bleibt, statt jeder Seite aufgezwungen zu werden.

Vorgesehene Zuordnung: aside neben dem Hauptinhalt über wb-grid oder ein anderes mitgeliefertes Layout-Primitiv.
Der Standardinhalt sollte ein wb-stack aus unterstützenden Blocks sein, optional gruppiert in einer wb-card oder einem wb-callout, wenn das zum Block-Inhalt passt.
wb-sidebar sollte nur verwendet werden, wenn die Seite explizit eine Docs-/App-Navigationshülle rendert, nicht für generische unterstützende Marketing-Inhalte.
Die aktuelle Implementierung ist schwach, weil sie noch eine eigene wb-public-sidebar-Hülle verwendet. Phase 2A entfernt den erzwungenen äußeren wb-card-Wrapper, damit innere Blocks selbst steuern, ob sie als Cards oder Callouts gerendert werden.

Vorgesehene Zuordnung: footer-Region, aufgebaut aus wb-section, wb-container und wb-grid oder wb-stack.
Navigationslisten sollten einfache Nav-/Listen-Primitive oder wb-link-list verwenden, wenn das mitgelieferte UI-Muster passt.
Unterstützende Content-Blocks dürfen im Footer normal gerendert werden; sie sollten keine footer-spezifischen Block-Renderer benötigen.
Die aktuelle Implementierung ist akzeptabel, weil sie nah an den mitgelieferten Layout-Primitiven bleibt, mit nur geringem CMS-spezifischem Footer-Chrome rund um das Cookie-Einstellungs-Element.

CMS-Block-Slug: header
Admin-Felder: text, level, anchor
Übersetzbare Felder: title-Text
Geteilte Felder: variant/Level, Ausrichtungseinstellung, Anker
Vorgesehene WebBlocks-UI-Ausgabe: semantisches <h1>-<h6> basierend auf level; optionale id aus dem geteilten Anker; kein erfundener Wrapper über das Überschriften-Element hinaus.
Aktuelle Implementierung: akzeptabel
TOC-Vertrag: explizite geteilte Anker sind die einzige unterstützte TOC-Quelle, und das öffentliche TOC sammelt verankerte header-Blocks aus demselben gerenderten Seitenbaum, einschließlich verschachtelter Layout-Nachfahren.
Hinweise für spätere Renderer-/Admin-Verbesserungen: das Ankerverhalten explizit halten, die wrapper-freie Ausgabe bewahren und die Überschriften-Semantik weiterhin durch Header statt durch einen parallelen Legacy-Block besitzen lassen.

CMS-Block-Slug: text
Admin-Felder: content
Übersetzbare Felder: content
Geteilte Felder: keine
Vorgesehene WebBlocks-UI-Ausgabe: gewöhnlicher Absatz-/Fließtext; einen mitgelieferten wb-stack-Rhythmus nur dann verwenden, wenn er für mehrere Textknoten benötigt wird.
Aktuelle Implementierung: akzeptabel
Import-/Sync-Zuordnungshinweis: text/plain_text nur für einfachen, reinen Fließtext ohne sicheres Inline-Formatierungs-Markup verwenden.
Hinweise für spätere Renderer-/Admin-Verbesserungen: diesen Block einfach halten und ihn nicht in einen Pseudo-Rich-Text-Block verwandeln.

CMS-Block-Slug: rich-text
Admin-Felder: content
Übersetzbare Felder: content
Geteilte Felder: keine
Vorgesehene WebBlocks-UI-Ausgabe: bereinigter Fließtext, eingehüllt in wb-rich-text wb-rich-text-readable unter Verwendung des mitgelieferten WebBlocks-UI-Rich-Text-Primitivs.
Aktuelle Implementierung: akzeptabel
Speichermodell: Rich Text speichert ein eingeschränktes, sicheres HTML-Fragment, keine Markdown-Marker. Erlaubte Tags sind p, strong, em, code, a[href], ul, ol, li und bei Bedarf br. Klassen, Styles, Event-Attribute, Überschriften, Medien, Tabellen, Buttons und nicht unterstütztes HTML werden bei der Bereinigung entfernt.
Admin-Verhalten: Der Admin-Editor ist eine abhängigkeitsfreie contenteditable-Oberfläche, die mit einem versteckten Formularfeld synchronisiert wird. Er ist bewusst auf Fließtext-Formatierung beschränkt und ersetzt nicht Header, Button, Media, Table, Layout, HTML oder andere dedizierte Blocktypen.
Import-/Sync-Zuordnungshinweis: Wenn importierter Fließtext sichere Inline-Formatierung, mehrere Absätze oder einfache Listen enthält, sollte er zu rich-text statt zu text werden.
Hinweise für spätere Renderer-/Admin-Verbesserungen: Rich Text auf sicheren redaktionellen Fließtext beschränkt halten. wb-rich-text bleibt das öffentliche Typografie-Primitiv. Überschriften, Medien, Buttons, Tabellen, Layout und rohe HTML-Komposition bleiben separate Blocks oder Features.

CMS-Block-Slug: html
Admin-Felder: content
Übersetzbare Felder: content
Geteilte Felder: keine
Vorgesehene WebBlocks-UI-Ausgabe: rohes vertrauenswürdiges HTML innerhalb des normalen öffentlichen Block-Wrappers.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: diesen Block nur für vertrauenswürdige redaktionelle/administrative Nutzung vorsehen, das XSS-Risiko klar dokumentieren und gewöhnliche Editoren für normale Inhalte nicht auf eingefügtes WebBlocks-HTML angewiesen sein lassen. Wenn vertrauenswürdiges HTML mitgeliefertes WebBlocks-UI-Overlay-Markup enthält, sollte die öffentliche Page-Shell diesen inneren Overlay-Inhalt in das gemeinsame, seiteneigene #wb-overlay-root hochziehen, statt doppelte Overlay-Roots inline zu rendern.

CMS-Block-Slug: section
Admin-Felder: title, variant, content
Übersetzbare Felder: title, content
Geteilte Felder: variant
Vorgesehene WebBlocks-UI-Ausgabe: Der Standard-Wrapper verwendet wb-section; explizite promo-Varianten dürfen auf wb-promo abgebildet werden, wenn das mitgelieferte Muster passt; CTA-Aktionen sollten aus Kind-Blocks kommen, nicht aus rohem HTML.
Aktuelle Implementierung: akzeptabel
Wrapper-Regel: Der Section-Block besitzt den echten <section class="wb-section ...">-Root und trägt data-wb-public-block-type="section" auf diesem Element. Generische öffentliche Block-Wrapper dürfen ihn nicht umhüllen.
Hinweise für spätere Renderer-/Admin-Verbesserungen: Standard-Sections stabil halten, promo als explizite Marketing-Variante behandeln und Kind-Buttons/Button-Gruppen strukturiert halten.
Promo-CTA-Verhalten: Kind-button-Blocks werden in wb-promo-actions gerendert; Nicht-Button-Kinder werden weiterhin außerhalb der CTA-Zeile gerendert.

header, section, container, grid, cluster, card und content_header sind Root-besitzende Layout-/Content-Shell-Blocks und sollten keinen generischen öffentlichen Wrapper aus der öffentlichen Block-Schleife erhalten.
Section besitzt bei Bedarf den semantischen <section class="wb-section">-Root.
Container, Grid und Cluster besitzen ihre eigenen nicht-semantischen Layout-Roots, sofern ein bestimmter Renderer nicht bewusst etwas anderes wählt.
Card besitzt seinen <article class="wb-card">-Root.
Card Header, Card Body und Card Footer besitzen ihre passenden WebBlocks-UI-Regions-Roots und definieren zusammen die normale öffentliche Card-Struktur.
Header besitzt seinen semantischen Überschriften-Root wie <h1> oder <h2>.
Content Header besitzt seinen semantischen <header class="wb-content-header">-Root und rendert seinen Titel immer als <h1 class="wb-content-title">.
Die Layout- und Card-Standardisierung in Phase 3 hält diese Root-besitzenden Blocks über die Renderer-Partials, Block::ownsPublicRoot(), die Vertrags-Registry, das schreibgeschützte Admin-Vertragsmodal und den Contracts-Audit-Befehl hinweg abgeglichen.

CMS-Block-Slug: hero
Admin-Felder: subtitle, title, content, variant
Übersetzbare Felder: subtitle als Eyebrow, title als Headline, content als unterstützender Text
Geteilte Felder: variant, Kind-Block-Struktur
Vorgesehene WebBlocks-UI-Ausgabe: wb-promo > .wb-promo-copy mit optionalem wb-eyebrow, wb-promo-title, wb-promo-text und wb-promo-actions
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Hero-CTA-Aktionen sollten aus Kind-button-Blocks kommen, rohes HTML sollte nicht für normalen Hero-Inhalt verwendet werden, und importierte Legacy-Hero-Einstellungen sollten nur als Fallback wirken, wenn die kanonischen übersetzten Felder leer sind.
Hero-CTA-Verhalten: Kind-button-Blocks werden in wb-promo-actions gerendert; Nicht-Button-Kinder werden in der CTA-Zeile ignoriert.
Wrapper-Regel: hero besitzt jetzt seinen eigenen Renderer-Root und platziert data-wb-public-block-type="hero" auf diesem Root, sodass die Slot-Schleife keinen generischen äußeren öffentlichen Wrapper hinzufügen darf.

CMS-Block-Slug: columns
Admin-Felder: title, subtitle, content, variant, wiederholbare column_items
Übersetzbare Felder: title, subtitle, content, Text der Kind-column_item-Blocks
Geteilte Felder: variant, Kind-Reihenfolge, Kind-Links, Struktur
Vorgesehene WebBlocks-UI-Ausgabe: Layout-Container für wiederholbare Kinder mit wb-grid, wb-grid-2, wb-grid-3, wb-grid-4 oder einem generischen wb-grid, wenn die Anzahl dynamisch ist.
Aktuelle Implementierung: akzeptabel
Varianten-Zuordnung:
cards -> Grid-Container, in dem jedes Kind als wb-card > .wb-card-body gerendert wird
plain -> Grid-Container mit ungerahmtem, gestapeltem Kind-Inhalt
stats -> Grid-Container, in dem Kind-Elemente als wb-stat gerendert werden
links -> wb-link-list, in der Kind-Elemente als Link-Listen-Zeilen gerendert werden
Hinweise für spätere Renderer-/Admin-Verbesserungen: Der Eltern-Block soll weiterhin für die Präsentationswahl verantwortlich sein, damit bestehender column_item-Inhalt einfach und wiederverwendbar bleiben kann.

CMS-Block-Slug: column_item
Admin-Felder: title, url, content
Übersetzbare Felder: title, content
Geteilte Felder: url
Vorgesehene WebBlocks-UI-Ausgabe: eine Grid-Zelle, die je nach Eltern- oder Element-Variante als einfacher Inhalt, wb-card, wb-stat, wb-link-list-item oder als andere mitgelieferte Zellendarstellung gerendert werden kann.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: column_item bleibt eine einfache Inhaltseinheit und überlässt die öffentliche Präsentation jetzt seinem Eltern-Block columns. Die aktuelle stats-Zuordnung ist bewusst konservativ, weil es noch kein dediziertes numerisches Wertfeld gibt.

CMS-Block-Slug: cta
Admin-Felder: subtitle, title, content, verwalteter primärer CTA, verwalteter sekundärer CTA, variant
Übersetzbare Felder: subtitle als Eyebrow, title als Überschrift, content als unterstützender Text, dazu die Beschriftungen untergeordneter button-Blöcke
Gemeinsame Felder: variant, CTA-URLs der Kind-Blöcke, Reihenfolge der Kind-Blöcke
Vorgesehene WebBlocks-UI-Ausgabe: Promo-artiger wb-card wb-promo-Abschnitt mit wb-promo-copy und wb-promo-actions
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: CTA-Beschriftungen auf untergeordneten Buttons in der Hoheit der Sprache (Locale) belassen, CTA-URLs gemeinsam halten und keine settings-gesteuerten CTA-Payloads wieder einführen.
Wrapper-Regel: cta besitzt jetzt sein eigenes Renderer-Root und setzt data-wb-public-block-type="cta" auf dieses Root; die Slot-Schleife darf daher keinen generischen äußeren öffentlichen Wrapper hinzufügen.

CMS-Block-Slug: feature-grid
Admin-Felder: title, subtitle, content, wiederholbare feature_items
Übersetzbare Felder: title, subtitle, content, Text untergeordneter feature-item-Blöcke
Gemeinsame Felder: Reihenfolge der Kind-Blöcke, Links der Kind-Blöcke, Struktur
Vorgesehene WebBlocks-UI-Ausgabe: dieselbe öffentliche Card-Grid-Struktur, die von columns.variant = cards verwendet wird
Aktuelle Implementierung: als Kompatibilitäts-Alias akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Feature Grid quellgestützt und dokumentiert halten, aber ausdrücklich festhalten, dass es derzeit an den gemeinsamen Columns-Cards-Renderer delegiert, statt eigenes Feature-Grid-Markup zu besitzen.

CMS-Block-Slug: feature-item
Admin-Felder: title, url, content
Übersetzbare Felder: title, content
Gemeinsame Felder: url
Vorgesehene WebBlocks-UI-Ausgabe: dieselbe kartenartige Element-Hülle, die column_item in der Columns-Cards-Darstellung verwendet
Aktuelle Implementierung: als Kompatibilitäts-Alias akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Feature Item weiterhin als quellgestützten, unterstützenden Kind-Block-Vertrag dokumentieren, solange es an die gemeinsame Column-Item-Cards-Darstellung delegiert.

CMS-Block-Slug: callout
Admin-Felder: title, variant, content
Übersetzbare Felder: title, content
Gemeinsame Felder: variant
Vorgesehene WebBlocks-UI-Ausgabe: Hinweis-/Alert-Verhalten wird auf wb-alert-* abgebildet; Sidebar-/Hilfe-Varianten können auf wb-callout abgebildet werden, falls dieses Primitive in WebBlocks UI existiert.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: die Tonalitäts-Zuordnung explizit halten und alternative Callout-Hüllen nur einführen, wenn die ausgelieferte UI sie besitzt.

CMS-Block-Slug: quote
Admin-Felder: content, title, subtitle
Übersetzbare Felder: content, title, subtitle
Gemeinsame Felder: keine
Vorgesehene WebBlocks-UI-Ausgabe: semantisches blockquote; die ausgelieferte Card-/Callout-Rahmung nur verwenden, wenn das Zitat bewusst als gerahmtes Testimonial bzw. als Karte präsentiert wird.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: eine ungerahmte semantische Zitat-Variante zulassen und testimonial nur verwenden, falls daraus ein eigenständiges, vollwertiges Muster wird.

CMS-Block-Slug: faq
Admin-Felder: title, content
Übersetzbare Felder: title, content
Gemeinsame Felder: keine
Vorgesehene WebBlocks-UI-Ausgabe: einfacher Frage-/Antwort-Inhalt in einer stabilen wb-card- und wb-stack-Hülle.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: FAQ bleibt einfach und abwärtskompatibel. Als Kind eines Blocks aus der Accordion-Familie fungieren title und content als Zusammenfassung bzw. Inhalt der Aufklappung.

CMS-Block-Slug: accordion
Admin-Felder: title, content
Übersetzbare Felder: title, content
Gemeinsame Felder: Struktur und Reihenfolge der Kind-Blöcke
Vorgesehene WebBlocks-UI-Ausgabe: semantische, gruppierte Aufklappung mit <details> und <summary>, ohne eigenes Accordion-JavaScript und ohne erfundene Klassen.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: die Aufklapp-Elemente liefern die Kind-Blöcke. Blöcke ohne nutzbare title- und content-Werte werden übersprungen, statt als leere Wrapper gerendert zu werden.

CMS-Block-Slug: faq-list
Admin-Felder: dieselben redaktionellen Erwartungen wie bei accordion
Übersetzbare Felder: vom übergeordneten Block und den Kind-Elementen geerbt
Gemeinsame Felder: Struktur und Reihenfolge der Kind-Blöcke
Vorgesehene WebBlocks-UI-Ausgabe: wie bei accordion; dieser Slug ist inzwischen ein Übergangs-Alias und kein eigenständiges, langfristiges Muster.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: alte Inhalte funktionsfähig halten, künftige gruppierte Aufklappungen aber in Richtung accordion lenken.

CMS-Block-Slug: tabs
Admin-Felder: title, subtitle, content
Übersetzbare Felder: title, subtitle, content
Gemeinsame Felder: keine
Vorgesehene WebBlocks-UI-Ausgabe: ein echtes interaktives Tabset, falls Tabs ein vollwertiger Block bleiben.
Aktuelle Implementierung: schwach
Hinweise für spätere Renderer-/Admin-Verbesserungen: Tabs sind ausdrücklich zurückgestellt, bis WebBlocks UI ein echtes Tabs-Muster ausliefert. Die aktuelle einfache Card-Darstellung bleibt nur als Kompatibilitäts-Fallback bestehen und wird nicht beworben.

CMS-Block-Slug: button
Admin-Felder: title, url, subtitle, variant
Übersetzbare Felder: title
Gemeinsame Felder: url, subtitle/Ziel, variant, optionale Anhang-Medienrelation
Vorgesehene WebBlocks-UI-Ausgabe: explizite wb-btn-Varianten-Zuordnung für primary, secondary, outline, ghost und danger; unbekannte Werte müssen auf wb-btn wb-btn-primary zurückfallen.
Aktuelle Implementierung: akzeptabel
Varianten-Zuordnung:
primary -> wb-btn wb-btn-primary
secondary -> wb-btn wb-btn-secondary
outline -> wb-btn wb-btn-outline
ghost -> wb-btn wb-btn-ghost
danger -> wb-btn wb-btn-danger
unbekannt oder leer -> wb-btn wb-btn-primary
Hinweise für spätere Renderer-/Admin-Verbesserungen: die Anhang-/Download-Kompatibilität isoliert halten, <button type="button"> nur rendern, wenn keine URL vorhanden ist, und einen vollwertigen Button-Group-Block erst formalisieren, wenn Redakteure ihn über Kind-Button-Zeilen hinaus benötigen.

Hero- und Promo-artige Abschnittsblöcke sollten CTAs mit untergeordneten button-Blöcken modellieren.
Promo-CTA-Zeilen werden in wb-promo-actions gerendert.
Außerhalb von Promo-Kontexten können gewöhnliche Aktionszeilen ausgelieferte Cluster-Utilities wie wb-cluster wb-cluster-2 verwenden.
Ein vollwertiger button-group-Block ist vorerst zurückgestellt; das aktuelle Kind-Button-Modell unterstützt strukturierte CTA-Zeilen bereits, ohne neue Block-Architektur einzuführen.

CMS-Block-Slug: image
Admin-Felder: media_id, subtitle, url, title
Übersetzbare Felder: title als Bildunterschrift, subtitle als Alt-Text
Gemeinsame Felder: media_id, url
Vorgesehene WebBlocks-UI-Ausgabe: semantisches figure, img und optionales figcaption; ausgelieferte Medien-/Card-Klassen nur verwenden, wenn das Bild bewusst gerahmt ist.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Phase 3 hält Bildunterschrift und Alt-Text jetzt auf dem Bild-Übersetzungspfad, bewahrt die optionale gemeinsame Link-URL und behält die wrapperfreie semantische Ausgabe bei, wenn Medien vorhanden sind.

CMS-Block-Slug: gallery
Admin-Felder: kompakte Gallery Items-Listenzeilen, gemeinsame Galerie-Darstellungseinstellungen und Metadaten-Modals pro Element
Übersetzbare Felder: pro Galerie-Element alt_text, caption, overlay_title und overlay_text über block_gallery_item_translations
Gemeinsame Felder: geordnete Auswahl und Reihenfolge der Galerie-Medien, Spalten, Abstand, Variante, Seitenverhältnis, Bildunterschriften-Modus, Overlay-Modus und Lightbox-Schalter
Vorgesehene WebBlocks-UI-Ausgabe: WebBlocks-Galerie-Muster mit dem Viewer unter #wb-overlay-root; die Interaktion sollten zuerst die ausgelieferten WebBlocks-UI-Galerie-Hooks steuern.
Aktuelle Implementierung: akzeptabel
Öffentlicher Rendering-Vertrag: Die Galerie gibt keine öffentliche Einleitungsüberschrift und keinen Einleitungsabsatz mehr aus. In älteren Datensätzen gespeicherte Galerie-Titel-/Beschreibungswerte können bestehen bleiben, werden vom öffentlichen Renderer aber ignoriert. Galerie-Medien mit festem Seitenverhältnis bewahren das vollständige Bild mit zentriertem Contain-Fitting, sodass Screenshot-artige Bilder in festen Kacheln nicht beschnitten werden.
Redaktioneller Vertrag: Wenn Abschnittsüberschriften oder erläuternder Text benötigt werden, vor dem Galerie-Block Content Header plus Plain Text oder Rich Text verwenden.
Hinweise für spätere Renderer-/Admin-Verbesserungen: Der aktuelle Renderer schreibt kanonische, geordnete Galerie-Medien über block_media, löst locale-eigene Texte pro Element über block_gallery_item_translations auf, bewahrt Legacy-Fallback-Elemente für ältere gespeicherte Inhalte und hält data-wb-gallery-target mit einem gemeinsamen Viewer-Modal unter #wb-overlay-root gekoppelt.

CMS-Block-Slug: download
Admin-Felder: title, subtitle, media_id, variant
Übersetzbare Felder: title, subtitle
Gemeinsame Felder: media_id, variant
Vorgesehene WebBlocks-UI-Ausgabe: Datei-CTA als wb-btn oder eine kompakte wb-card plus wb-btn, wenn die Variante mehr Kontext benötigt.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Phase 3 hält sichtbare Beschriftung und Hilfetext jetzt in den Textübersetzungen, bewahrt die gemeinsame Hoheit über Medien und Button-Variante und unterdrückt fehlerhafte CTA-Ausgabe, wenn keine Medienquelle existiert.

CMS-Block-Slug: contact_form
Admin-Felder: heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
Übersetzbare Felder: heading, intro_text, submit_label, success_message
Gemeinsame Felder: recipient_email, send_email_notification, store_submissions
Vorgesehenes Verhalten: Die öffentliche Übermittlung speichert zuerst die Nachricht und versucht anschließend eine synchrone E-Mail-Benachrichtigung an den aufgelösten Empfänger; Admin-Ansichten sollten einen kompakten Benachrichtigungsstatus und sichere Fehlerdetails anzeigen, wenn die Zustellung fehlschlägt.
Öffentlicher Submit-Endpunkt: natives Browser-Formular POST /contact-messages mit CSRF, CMS-eigenem verstecktem, generiertem Anti-Spam-Prüffeld, Pflichtvalidierung für name, email und message, optionalem subject und generischem Erfolgsverhalten bei Übermittlungen mit ausgefülltem Prüffeld.
Hinweise: Zuerst gewinnt die Empfänger-Übersteuerung am Block, dann das contact_recipient_email der aktuellen öffentlichen Site, dann CONTACT_RECIPIENT_EMAIL und zuletzt MAIL_FROM_ADDRESS als sicherer lokaler Fallback, wenn kein expliziter Kontakt-Empfänger konfiguriert ist.

CMS-Block-Slug: video
Admin-Felder: title, content, url, media_id
Übersetzbare Felder: title, content
Gemeinsame Felder: url, media_id
Vorgesehene WebBlocks-UI-Ausgabe: semantisches <video controls> für direkte Quellen oder ein sicheres Provider-<iframe> nur für bekannte YouTube-/Vimeo-URLs, innerhalb einer einfachen wb-card-Hülle.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Phase 3 gibt Video jetzt ein eigenes Admin-Formular und einen eigenen Speicherpfad, hält sichtbaren Text übersetzt, bewahrt das Rendering mit Vorrang für gehostete Medien und fällt bei sicheren, unbekannten URLs auf einen einfachen externen Link zurück, statt unsicher einzubetten.

CMS-Block-Slug: audio
Admin-Felder: title, content, url, media_id
Übersetzbare Felder: title, content
Gemeinsame Felder: url, media_id
Vorgesehene WebBlocks-UI-Ausgabe: semantisches <audio controls> innerhalb einer einfachen wb-card-Hülle.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Phase 3 gibt Audio jetzt ein eigenes Admin-Formular und einen eigenen Speicherpfad, hält sichtbaren Text übersetzt und unterdrückt leere Player-Steuerelemente, wenn keine nutzbare Quelle existiert.

CMS-Block-Slug: file
Admin-Felder: title, content, url, media_id
Übersetzbare Felder: title, content
Gemeinsame Felder: url, media_id
Vorgesehene WebBlocks-UI-Ausgabe: kompakte Dateikarte mit einer wb-btn wb-btn-secondary-Aktion zum Herunterladen/Öffnen.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Phase 3 gibt File jetzt ein eigenes Admin-Formular und einen eigenen Speicherpfad, hält sichtbaren Text übersetzt und hält den gemeinsamen Medien-oder-URL-Quellvertrag explizit, ohne leere, ungültige Anker zu rendern.

CMS-Block-Slug: map
Admin-Felder: title, content, url
Übersetzbare Felder: keine
Gemeinsame Felder: title, content, url
Vorgesehene WebBlocks-UI-Ausgabe: einfache Standortzusammenfassung mit einem externen Open map-Button, kein eigenes Karten-Widget.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: die Implementierung link-orientiert halten, solange kein echtes ausgeliefertes Karten-/Embed-Muster verfügbar ist.

CMS-Block-Slug: slider
Admin-Felder: geordnete Galerie-Assets und optionaler Text
Übersetzbare Felder: keine
Gemeinsame Felder: Assets und Struktur
Vorgesehene WebBlocks-UI-Ausgabe: kein beworbener Phase-4-Renderer; nach Möglichkeit stattdessen gallery oder andere strukturierte Medien-Blöcke verwenden.
Aktuelle Implementierung: schwach
Hinweise für spätere Renderer-/Admin-Verbesserungen: Der Slider bleibt zurückgestellt, weil es kein bestätigtes, ausgeliefertes WebBlocks-UI-Karussell-Muster gibt, auf das sich eine Standardisierung lohnen würde.

CMS-Block-Slug: code
Admin-Felder: title, content
Übersetzbare Felder: title, content
Gemeinsame Felder: optionales settings.language
Vorgesehene WebBlocks-UI-Ausgabe: escapter Quelltext innerhalb von semantischem <pre><code>, ohne injiziertes HTML und ohne Syntax-Highlighting-Abhängigkeit.
Aktuelle Implementierung: akzeptabel
Hinweis zur Import-/Sync-Zuordnung: rohe oder mehrzeilige Snippets wie <pre><code>-Beispiele und Paket-Include-Blöcke sollten zu code werden, nicht zu rich-text.
Hinweise für spätere Renderer-/Admin-Verbesserungen: das Code-Rendering sicher und abhängigkeitsfrei halten. Optionale Sprach-Metadaten können aus den Einstellungen bereitgestellt werden, aber ein vollwertiger Code-Editor oder ein Syntax-Highlighting-Stack liegt für Phase 3 bewusst außerhalb des Umfangs.

CMS-Block-Slug: toc
Admin-Felder: title
Übersetzbare Felder: title
Gemeinsame Felder: keine
Vorgesehene WebBlocks-UI-Ausgabe: wb-link-list, aufgebaut aus vorhandenen verankerten header-Blöcken derselben Seite.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: Die Phase-3-Implementierung bleibt bewusst minimal. Sie rendert nur, wenn Header-Blöcke bereits explizite Anker-IDs bereitstellen, und versucht kein komplexes Überschriften-Parsing und keine automatisch erzeugten Anker.

CMS-Block-Slug: navigation-auto
Admin-Felder: navigation_menu_key
Übersetzbare Felder: keine
Gemeinsame Felder: settings.menu_key
Vorgesehene WebBlocks-UI-Ausgabe: Site-Navigationsliste mit einfachen Nav-/Listen-Primitiven oder, wo passend, wb-link-list; keine Docs-Sidebar vortäuschen, sofern die Seitenhülle nicht wirklich eine Docs-Hülle ist.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: den Block auf das Rendern von Navigationsbäumen fokussieren und die Slot-/Seitenhülle entscheiden lassen, ob die Ausgabe Header-, Footer- oder Docs-Navigation ist.

CMS-Block-Slug: menu
Admin-Felder: navigation_menu_key
Übersetzbare Felder: keine
Gemeinsame Felder: settings.menu_key
Vorgesehene WebBlocks-UI-Ausgabe: wie navigation-auto; dies bleibt ein Legacy-Alias für migrierte Daten.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: die Unterstützung alter Inhalte beibehalten, aber in der Admin-UX und in künftigen Seeds navigation-auto bevorzugen.

tabs, slider, menu und faq-list sind im CMS-Katalog weiterhin Legacy-Slugs aus der Entwurfsära und keine veröffentlichten Kernverträge.
showcase-list und contact-info existieren weiterhin nur als Kompatibilitätsblöcke für das öffentliche Rendering und werden in dieser Phase nicht in den veröffentlichten Kernkatalog befördert.
Diese Phase dokumentiert diese Pfade ehrlich, bewahrt das Kompatibilitäts-Rendering dort, wo es bereits ausgeliefert wird, und ergänzt eine sichere Link-Bereinigung für settings-gesteuerte öffentliche Links, ohne ein neues Tabs- oder Slider-JavaScript-System einzuführen.

CMS-Block-Slug: contact_form
Admin-Felder: heading, intro_text, submit_label, success_message, recipient_email, send_email_notification, store_submissions
Übersetzbare Felder: title/Überschrift, content/Einleitung, submit_label, success_message
Gemeinsame Felder: recipient_email, send_email_notification, store_submissions
Vorgesehene WebBlocks-UI-Ausgabe: Formularfelder verwenden WebBlocks-UI-Formular-Primitive; die Submit-Aktion verwendet wb-btn; transientes Erfolgs-Feedback wird einmalig als WebBlocks-UI-Toast unter dem gemeinsamen öffentlichen #wb-overlay-root gerendert, während Validierungsfehler und vom Nutzer korrigierbare Fehler mit wb-alert inline beim Formular bleiben.
Aktuelle Implementierung: akzeptabel
Hinweise für spätere Renderer-/Admin-Verbesserungen: strukturierte Formularfelder bewahren, operative Einstellungen aus redaktionellem Text heraushalten, Standard-Empfänger auf Site-Ebene im Site-Datensatz statt in beliebigem Block-JSON halten und Redakteure weder rohes Formular-Markup einfügen noch mailto: als Ersatz für die Übermittlung verwenden lassen.

CMS-Block	Aktueller Stand	Gewünschte Richtung	Hinweise
card-grid	nur öffentliches Rendering	sollte transitional bleiben	Der Renderer erzeugt jetzt dieselbe wb-grid- und wb-card-Struktur wie columns.variant = cards, hängt aber weiterhin von settings.items ab. Für neue strukturierte Inhalte Columns bevorzugen.
showcase-list	nur öffentliches Rendering	sollte Fallback/Custom bleiben	Dies ist derzeit showcase-spezifischer Seed-Inhalt und sollte nicht zum Kern werden, sofern sich das Muster nicht über mehrere Sites wiederholt. Öffentliche Bild-Trigger sollten weiterhin dem ausgelieferten Galerie-Vertrag folgen, indem sie data-wb-gallery-target ausgeben und ein gemeinsames Viewer-Modal unter #wb-overlay-root registrieren.
contact-info	nur öffentliches Rendering	sollte vollwertig werden	Wenn Redakteure weiterhin Kontakt-Metadaten-Karten verwenden, ist ein kleiner strukturierter Block besser als settings-gesteuerter Custom-Inhalt. Das aktuelle Kompatibilitäts-Rendering ignoriert unsichere Settings-URLs jetzt, statt ungültige oder gefährliche Anker auszugeben.
code	vollwertiger öffentlicher Renderer	akzeptabel	Sicheres -Rendering ist jetzt vorhanden; reichhaltigere Editor-Funktionen bleiben optionale zukünftige Arbeit.
list	vollwertiger öffentlicher Renderer	akzeptabel	Dediziertes zeilenbasiertes Listen-Rendering existiert jetzt; Kompatibilität für Legacy-Inhalte aus Settings beibehalten.
table	vollwertiger öffentlicher Renderer	akzeptabel	Dediziertes zeilenbasiertes Tabellen-Rendering existiert jetzt; Kompatibilität für Legacy-Settings-Zeilen beibehalten.
accordion	vollwertiger öffentlicher Renderer	akzeptabel	Gruppierte Aufklappung verwendet jetzt semantisches und Kind-Blöcke statt Fallback-Markup aus Settings.
feature-grid	veröffentlichter Kompatibilitäts-Alias	sollte transitional bleiben	Der öffentliche Renderer delegiert an columns.variant = cards; für neue Inhalte Columns bevorzugen, Feature Grid aber dokumentiert lassen, weil es quellgestützt und ausgeliefert ist.
stats	nur Alias	sollte in Columns aufgehen	Der öffentliche Renderer delegiert an den bestehenden columns.variant = stats-Pfad und sollte als Alias-Verhalten dokumentiert bleiben statt als eigenständiger veröffentlichter Vertrag.
metric-card	vollwertiger Alias	sollte in Stat-Primitive aufgehen	Der öffentliche Renderer verwendet jetzt dieselbe wb-stat-Richtung wie die Columns-Stats-Variante.
logo-cloud	nur Fallback	sollte vollwertig werden	Nur befördern, wenn es einen wiederholbaren Bedarf an strukturierten Logo-/Medienzeilen gibt.
testimonial	nur Alias	sollte in Quote aufgehen	Der öffentliche Renderer delegiert an die Testimonial-Variante des Zitats und sollte als Alias-Verhalten dokumentiert bleiben statt als eigenständiger veröffentlichter Vertrag.
timeline	nur Fallback	sollte vollwertig werden	Nur mit strukturierten Meilensteinen und einem klaren, ausgelieferten UI-Muster befördern.
pricing	nur Fallback	sollte vollwertig werden	Ein Pricing-Block braucht strukturierte Felder für Plan, Features und CTA, um eine Beförderung wert zu sein.
toc	vollwertiger öffentlicher Renderer	akzeptabel	Minimales TOC-Rendering nutzt jetzt bestehende Header-Anker und wb-link-list; das Verhalten für aktive Abschnitte ist weiterhin zurückgestellt.
breadcrumb	nur Fallback	sollte vollwertig werden	Nur hinzufügen, wenn die öffentliche Hülle wirklich eine Breadcrumb-Navigation benötigt.
cookie-notice	nur Fallback	sollte Fallback/Custom bleiben	Die öffentliche Consent-UI lebt bereits in der Layout-Hülle; dieser Block sollte daher nicht mit dem gemeinsamen Datenschutz-Muster konkurrieren.

Blade-Renderer müssen ausgelieferte wb-*-Klassen bevorzugen.
Keine neuen einmaligen öffentlichen CSS-Klassen, sofern sie nicht als WebBlocks-UI-Lücke dokumentiert sind.
Keine Inline-Skripte in Block-Renderern.
Interaktive Blöcke müssen zuerst die ausgelieferten WebBlocks-UI-Daten-Hooks verwenden.
CMS-spezifisches JS gehört nur bei Bedarf in public/cms/js.
Overlay-, Dialog- und Modal-Inhalte müssen #wb-overlay-root verwenden.
Admin-Felder dürfen Redakteure bei normalen Blöcken nicht zwingen, rohes WebBlocks-UI-HTML einzufügen.
Blöcke sollten wann immer möglich strukturierte Felder und Varianten statt rohem HTML bereitstellen.
README.md muss nach wesentlichen Änderungen am Renderer- oder Admin-Verhalten aktualisiert werden.

Nur Dokumentation.
Renderer-Vertrag festlegen.
Noch kein Renderer-Rewrite.

Öffentliches Layout und Slot-Wrapper angleichen.
Sicherstellen, dass der Hauptinhalt dort, wo es passt, mit wb-content-shell gerendert werden kann.
Tests für die Klassen-Ausgabe von Shell und Slot ergänzen.

card-grid, button-group und künftige eigenständige Stats- oder Testimonial-Muster erst dann vollwertig machen, wenn sie echte, produktseitig verantwortete Verträge statt Aliasse werden.
Bei Bedarf Admin-Formulare und Unterstützung im Übersetzungs-Registry ergänzen.

Phase 3 abgeschlossen: Die öffentlichen Kern-Blöcke sind jetzt an den WebBlocks-UI-Primitiven ausgerichtet.

Bestehende Seed-/Demo-Dokumentationsinhalte auf vollwertige Blöcke migrieren.
Die Abhängigkeit von rohem HTML oder settings.items überall dort entfernen, wo ein strukturierter Block existiert.

Verifizierte WebBlocks-UI-Primitive

Layout-Modi in Phase 2B

Matrix

Seitenlayout und Slots

Öffentliches Layout

Karte

Slot-Wrapper

Header-Slot

Main-Slot

Sidebar-Slot

Footer-Slot

Zentrale Inhaltsblöcke

`header`

`text`

`rich-text`

`html`

`section`

Layout-Wrapper-Regel

`hero`

`columns`

`column_item`

`cta`

`feature-grid`

`feature-item`

`callout`

`quote`

`faq`

`accordion`

`faq-list`

`tabs`

`button`

CTA-Zeilen

`image`

`gallery`

`download`

`contact_form`

`video`

`audio`

`file`

`map`

`slider`

`code`

`toc`

`navigation-auto`

`menu`

Legacy-/Übergangshinweis zu Phase 3

`contact_form`

Nur öffentlich gerenderte oder schwache Blöcke

Renderer-Regeln

Phasenplan

Phase 1

Phase 2

Phase 3

Phase 4