Footer-SDC-Schema — Figma-aligned 4-Column-Topology, abstrakte Slots durch semantische ersetzt
footer_first/_last/_utility_first/_utility_last) + align-Prop auf 6 semantische Slots (company_col/nav_col/highlights_col/kontakt_col/utility_links/copyright) umgestellt. Drei neue Drupal-Menüs (footer_navigation/_highlights/_kontakt) inkl. drei vorkonfigurierter Canvas-Menu-Blocks. Schema-Bruch akzeptiert — der bestehende Footer war Platzhalter, kein Live-Inhalt. Topology fix laut Figma 61622:33123, keine Variants.
Kontext
Der ursprüngliche Footer wurde in ADR-0008 (Header-Navbar-Slot-Refactor) am Rand miteingeführt: zwei Slot-Paare (footer_first/_last, footer_utility_first/_last) plus ein align-Boolean-Prop. Die Bezeichnungen waren bewusst abstrakt, weil zu dem Zeitpunkt kein finalisiertes Figma vorlag und das Schema flexibel bleiben sollte.
Mit P2503-84 liegt das Figma-Design figma.com/design/CHHDfbpX8Ys2LBiGs5HVK0, Node 61622:33123 vor und zeigt eine konkrete, feste Topology:
- Top-Bereich (4 Spalten, responsiv 1→2→4): „Company & Social", „Navigation", „Highlights", „Kontakt"
- Bottom-Bar (mit dashed Lime-Border): „Utility-Links" (Impressum / Datenschutz / …) links, „Copyright" rechts
- Dark-Variante: navy BG (
--brand-dark-blue) + Lime-Hover-Akzente + ivory-Copyright-Text - Keine Layout-Varianten (keine alternative Spaltenzahl, kein Alignment-Switch im Figma)
Die ursprünglichen 4 Slots passen zur neuen Topology nicht eindeutig: „Branding & Social" (ehemals footer_first) entspricht zwar grob company_col, aber die drei mittleren Spalten (Nav/Highlights/Kontakt) fehlten — sie hätten in einem einzigen footer_last-Slot landen müssen, was Editor-Selektivität (z.B. „lass die Highlights-Spalte weg") unmöglich gemacht hätte.
Drei zusätzliche Drupal-Menüs (footer_navigation, footer_highlights, footer_kontakt) werden vor-konfiguriert, weil die Inhalts-Editoren explizit nach getrennten Menü-Strukturen gefragt haben — anders als beim Header (eine Hauptnavigation) sollen Highlights und Kontakt nicht im selben Menü-Tree wie die Footer-Navigation hängen.
accepted für den Header-Bereich (Navbar-SDC-Schema, logo/navigation/links-Slots, 1280-px-Content-Bound). Nur der dort am Rand mitdefinierte Footer-Schema-Teil wird durch dieses ADR ersetzt. Querverweis: solcom:amends="0008".Entscheidung
Footer-SDC-Schema wird Figma-aligned umgestellt. Konkret:
| Bisher (ADR-0008) | Neu (ADR-0033) | Inhalt |
|---|---|---|
footer_first | company_col | Logo, Company-Beschreibung, Social-Menu |
| (neu) | nav_col | system_menu_block:footer_navigation |
| (neu) | highlights_col | system_menu_block:footer_highlights |
footer_last | kontakt_col | system_menu_block:footer_kontakt + ggf. CTA |
footer_utility_first | utility_links | Impressum / Datenschutz / Cookie-Einstellungen |
footer_utility_last | copyright | Copyright-Textblock |
align-Prop ersatzlos gestrichen. Figma zeigt keine Alignment-Variante. Bei späterer Bedarfslage eigener ADR.- Drei neue
system.menu.*-Konfigs:footer_navigation,footer_highlights,footer_kontakt. Vor-befüllt mit den vom Inhalts-Team genannten Default-Links; Editoren passen via/admin/structure/menuan. - Drei vorkonfigurierte Canvas-Menu-Blocks (
canvas.component.block.system_menu_block.footer_*) verdrahten die neuen Menüs auf die jeweiligen Slots. - Bestehende
canvas.page_region.byte_theme.footer.ymlwird Schema-konform refakteriert. Migration der bestehenden Slot-Inhalte ist unproblematisch, weil der Footer aufdevelopbislang ausschließlich Platzhalter-Inhalt enthielt (kein Live-Editor-Inhalt im Production-DB-State). - Social-Menu rendert via
menu--social.html.twigaus dem bestehendensystem.menu.social. Plattform-Detection (xing/linkedin/instagram) erfolgt überbyte_theme_preprocess_menu__social()aus dem URL-Host — kein URL-Substring-Sniffing im Template. - Brand-Token-Reuse statt Inline-Hex. Footer nutzt Tailwind-v4-Color-Aliases (
bg-brand-dark-blue,border-brand-lime,decoration-brand-lime,text-brand-lime-tint) — keine arbitrary Hex-Klassen. Drei zugehörige Brand-Tokens (--brand-lime-tint,--brand-cream,--brand-hover-blue) wurden intheme.brand.cssergänzt. - Light-Variante (ivory BG) Out of Scope — analog zur Navbar-Entscheidung in ADR-0027. Kein neuer Color-Prop am Footer-Schema. Bei späterer Bedarfslage eigener ADR.
Rejected alternatives
Expand each rejected option to see the rationale.
Bestehende abstrakte 4 Slots beibehalten (footer_first/_last/_utility_*) rejected
Die mittleren drei Figma-Spalten (Nav, Highlights, Kontakt) hätten in einem einzigen footer_last-Slot kollabieren müssen. Damit wäre weder Editor-Selektivität pro Spalte möglich (eine Spalte kommentarlos weglassen), noch konsistente Spalten-Spacing-Mechanik. Die generischen Slot-Namen verschleiern zudem die Layout-Intent und erschweren Onboarding neuer Editoren / Theme-Developer.
Props-Driven Layout (column_count, layout_variant) rejected
Hätte SDC-Schema-Komplexität (Enum-Prop in Canvas) ohne realen Anwendungsfall erzeugt. Figma zeigt exakt eine Layout-Variante. Premature configurability bricht das Karpathy-„Simplicity First"-Prinzip. Bei künftiger Bedarfslage (z.B. 3-Column-Subpage-Footer) eigenes Schema oder eigene SDC.
Footer-Komplett-Implementation als separates Ticket statt P2503-84 rejected
Die solcom-review-Achse markierte die Footer-Implementation initial als „Spec-Creep" — Footer war im ursprünglichen PRD-Scope von P2503-84 als Out-of-Scope deklariert. Owner-Entscheidung (Marc, 2026-05-16): Footer bleibt im PR-Scope, weil (a) Header / Navbar / Footer eine kohärente Page-Shell sind und atomisches Deployment den Visual-Bruch im Live-System vermeidet, (b) die Inhalts-Editoren auf den Footer-Refresh warten, und (c) der Schema-Bruch ohne Live-Daten-Migration auskommt. Trade-off dokumentiert in diesem ADR statt Folgeticket.
Eigene SDC pro Footer-Spalte (footer-column) rejected
Hätte vier Slot-Wrapper-SDCs erzeugt, was Canvas-Tree-Tiefe und Render-Cycles ohne Mehrwert erhöht. Die Spalten haben gemeinsame Typografie + Hover-Styles (_footer_link in der Twig), aber kein internes Layout das ein SDC rechtfertigen würde. html_cva-Wrapper-Variablen im Footer-SDC reichen.
Plattform-Detection per item.original_link.getPluginId() rejected
Der getPluginId()-Wert für menu_link_content-Items ist menu_link_content:<uuid> — kein semantischer Plattform-Identifier. Ein dediziertes Plattform-Feld am Menü-Item-Entity-Bundle wäre zwar sauberer, erfordert aber Schema-Änderung + Migration für drei Bestands-Menüpunkte. Die gewählte Lösung (Host-Parse via parse_url im Preprocess-Hook) ist robust gegen Regional-Domains (xing.de, linkedin.cn) und Pfad-Suffixe, ohne Schema-Eingriff.
Consequences
- Schema-Bruch —
footer.component.ymlauf 6 semantische Slots umgestellt.align-Prop entfernt. Twig-Template (footer.twig) komplett refakteriert. - Drei neue Drupal-Menüs (
system.menu.footer_navigation,system.menu.footer_highlights,system.menu.footer_kontakt) inconfig/sync/. - Drei vorkonfigurierte Canvas-Menu-Blocks (
canvas.component.block.system_menu_block.footer_*.yml) verdrahten die Menüs auf die jeweiligen SDC-Slots. canvas.page_region.byte_theme.footer.ymlwird auf das neue Schema migriert (im PR enthalten). Bestehender Footer war Platzhalter — keine inhaltliche Datenmigration nötig.menu--social.html.twignutztbyte_theme_preprocess_menu__social()für robuste Host-basierte Plattform-Detection; URL-Substring-Sniffing im Template entfällt.theme.brand.cssbekommt drei neue Brand-Tokens (--brand-lime-tint,--brand-cream,--brand-hover-blue) und zugehörige Tailwind-v4-Color-Aliases — kein arbitrary Hex mehr in Footer / Navbar.- ADR-0008 bleibt
acceptedfür den Header-Bereich. Querverweis (solcom:amends="0008") signalisiert, dass nur der Footer-Schema-Teil ersetzt wurde. - Light-Variante des Footers ist explizit nicht Bestandteil von P2503-84 und erfordert bei Bedarf eigenen ADR.