fotospiel-app/docs/archive/prp/marketing-frontend-unification.md

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).