Hierarchische Navigation

Erweiterung der Site-Navigation um Unterseiten und Unter-Unterseiten plus Container-Items ohne eigenen Link.

Anforderung

Aktuell ist navigation.nav_json ein flaches items[]-Array (label + page_key/href). Public-Sites brauchen aber Drop-Down-Menüs für strukturierte Inhaltsbereiche (Provio: Service-Kategorien; Baume: Tour-Kalender nach Jahr; etc.).

Festgelegte Eckpunkte (Brainstorm 2026-04-29)

AspektEntscheidung
Hierarchie-Tiefe3 Ebenen fix — Top + Sub + Sub-Sub. Reicht für alle realen Use-Cases, hält Datenmodell schlank, vermeidet UX-Schmerz auf Mobile.
Container-ItemsJa — Top-Level- und Sub-Items können „kein Link” sein und dienen nur als Aufklapp-Anker für ihre Children.
Desktop-PatternBeides, pro Top-Level konfigurierbar: klassisches Single-Column-Dropdown ODER Mega-Menu (mehrspaltig).
Mobile-PatternSlideout-Akkordeon (Eltern-Items klappen Children aus).
Editor-UXFlache Liste mit Indent-Buttons (Tab/Shift-Tab oder ←/→) — schnell zu bauen, alexium-konform.

Offene Punkte für Implementation-Sprint

  • Datenmodell: nested children[] im bestehenden nav_json (einfach, aber harder to query) ODER eigene Tabelle navigation_item mit parent_navigation_item_id (sauberer, mehr Migrationsaufwand). Entscheidung per ADR.
  • Render-Logik: Lizenzmodell und Theme-Marketplace bleiben unberührt — nur NavigationHandler (siehe includes/classes/Renderer/Handler/NavigationHandler.class.php) wird erweitert.
  • Mega-Menu-Spalten: wieviel maximal? Bilder pro Spalte erlauben? Out-of-Scope für v1, nachziehen wenn ein Tenant es braucht.
  • Active-State über Hierarchie: wenn Sub-Page aktiv ist, soll der Top-Level auch --active zeigen? Standardpattern: ja.
  • Container-Items klickbar? Click auf einen Container öffnet Dropdown statt zu navigieren. Auf Mobile ist das eindeutig (Akkordeon-Toggle), auf Desktop ggf. expliziter Caret-Indikator nötig.

Zusammenhänge