# Vereinheitlichung des Marketing-Frontends: Von Hybrid (Blade + React) zu konsistentem Inertia/React-Layout

## Problemstellung
Das aktuelle Marketing-Frontend kombiniert Blade-Templates (z.B. für statische Seiten wie Blog, Legal) mit Vite/React-Komponenten (z.B. Packages, Register). Bei rein React-gerenderten Seiten fehlt das Layout (Header, Footer) und das Styling (z.B. Aurora-Gradient, Fonts), was zu inkonsistentem UX führt:
- Blade-Seiten: Vollständiges Layout via @extends('layouts.marketing').
- React-Seiten: Nur Komponente, kein Wrapper → Kein Header/Footer, anderes Styling.

Ziel: Vollständige Migration zu Inertia.js für SPA-ähnliche Konsistenz, mit einem zentralen React-Layout für alle Marketing-Seiten. Vorteile: Einheitliches Design, bessere Navigation, einfachere Wartung.

## Architektur-Vorschlag
### 1. Kernkomponenten
- **MarketingLayout.tsx** (resources/js/layouts/MarketingLayout.tsx): Wrapper für alle Marketing-Seiten.
  - Header: Logo, Navigation (Home, Packages, Blog, Occasions, Register/Login).
  - Hauptinhalt: `{children}` (die spezifische Page-Komponente).
  - Footer: Impressum, Datenschutz, Social-Links, Copyright.
  - Styling: Tailwind-Klassen für Aurora-Gradient (bg-aurora-enhanced), Fonts (Playfair Display für Überschriften, Montserrat für Text).
- **Globale Styles** (resources/css/app.css):
  - @font-face für Montserrat und Playfair Display (via Google Fonts oder lokal).
  - .bg-aurora-enhanced: radial-gradient(circle at 20% 80%, #a8edea 0%, #fed6e3 50%, #d299c2 100%) + linear-gradient + animation (shadcn-Style).
  - Theme: Primärfarbe #FFB6C1, responsive (mobile-first).

### 2. Routing & Controller
- **web.php** (routes/web.php): Alle /marketing/*-Routes zu Inertia::render umstellen.
  - Beispiel: Route::inertia('/marketing/packages', 'Marketing/Packages');
- **MarketingController.php** (app/Http/Controllers/MarketingController.php):
  - Methoden (z.B. packages(), blog(), register()) liefern Props (z.B. packages: Package::all()->map(fn($p) => ['id' => $p->id, 'features' => $p->features, 'limits' => $p->limits])).
  - Für dynamische Inhalte: DB-Queries (z.B. BlogPosts für /blog).

### 3. Page-Komponenten
- Alle Marketing-Seiten als React/TSX (resources/js/pages/marketing/*.tsx):
  - z.B. Packages.tsx: Rendert Paket-Karten in Grid/Carousel (shadcn), mit Modal für Details/Upsell.
  - Wrapper: In App.tsx oder router.tsx: if (route.startsWith('/marketing')) return `<MarketingLayout><Page /></MarketingLayout>`;
- Migration-Reihenfolge:
  1. Statische Seiten (Home, Blog-Index): Von Blade zu Inertia.
  2. Dynamische (Packages, Register): Props integrieren.
  3. Legal-Seiten: Als einfache Inertia-Pages (statischer Text).

### 4. Technische Umsetzung
- **Inertia-Setup**: Stelle sicher, config/inertia.php hat middleware für SSR (optional) und shared props (z.B. auth, flash).
- **Auth-Integration**: usePage().props.auth für CTAs (z.B. Login-Button im Header).
- **Responsive Design**: Tailwind: block md:hidden für Mobile-Carousel in Packages.
- **Fonts & Assets**: Vite-Plugin für Fonts/SVGs; preload in Layout.
- **Analytics (Matomo)**: Aktivierung via `.env` (`MATOMO_ENABLED=true`, `MATOMO_URL`, `MATOMO_SITE_ID`). `AppServiceProvider` teilt die Konfiguration als `analytics.matomo`; `MarketingLayout` rendert `MatomoTracker`, der das Snippet aus `/docs/piwik-trackingcode.txt` nur bei erteilter Analyse-Zustimmung lädt, `disableCookies` setzt und bei jedem Inertia-Navigationsevent `trackPageView` sendet. Ein lokalisierter Consent-Banner (DE/EN) übernimmt die DSGVO-konforme Einwilligung und ist über den Footer erneut erreichbar.
- **Tests**: E2E mit Playwright (z.B. navigate to /packages, check header/footer presence).

### 5. Diagramm: Layout-Struktur
```
MarketingLayout.tsx
├── Header (Navigation, Logo)
├── {children} (z.B. Packages.tsx)
│   ├── Hero (Aurora-Gradient)
│   ├── Content (Grid/Carousel)
│   └── CTA-Section
└── Footer (Legal-Links)
```

### 6. Migrations-Schritte (für Code-Modus)
1. Erstelle MarketingLayout.tsx und integriere in Router.
2. Migriere eine Test-Seite (z.B. /packages): Controller + Page-Komponente.
3. Passe app.css an (Fonts, Gradients).
4. Test: npm run dev, Browser-Check auf Layout-Konsistenz.
5. Vollständige Migration: Alle Blade-Seiten umstellen.
6. Edge-Cases: SEO (Inertia Head), Performance (Lazy-Loading).

### 7. Risiken & Mitigation
- Layout-Brüche während Migration: Fallback zu Blade via Feature-Flag.
- Styling-Konflikte: CSS-Isolation mit Tailwind-Prefix.
- Performance: Code-Splitting für große Pages.

Dieser Plan basiert auf bestehender Struktur (docs/prp/ als Referenz). Nach Umsetzung: Update PRP (docs/prp/01-architecture.md).
