gitmedia/markemacht
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
markemacht/dev/audit-formular-cookies/UMSETZUNGSPLAN.md
Kevin Adametz 1f7c0aa430 feat(marketing): Audit-Anfrageformular als Livewire-Komponente 
Das markemacht.de-Anfrageformular (Audit-Modal) war nach der Laravel-
Integration ohne Endpoint. Es wird jetzt serverseitig über Livewire
verarbeitet statt über das alte statische PHP-Skript.

- AuditAnfrage-Mailable + Mail-View, Reply-To = Absender
- config/marketing.php: Empfänger via MARKETING_ANFRAGE_TO (Default info@markemacht.de)
- Livewire-SFC web.audit-form: Validierung (dt.), Honeypot, Rate-Limit (3/10 Min),
  dispatch('audit-sent') schließt das Modal
- Modal-Markup auf <livewire:web.audit-form /> umgestellt
- Feature-Tests (Validierung, Versand, Honeypot, Throttle)
- Entwicklungsplan unter dev/audit-formular-cookies/

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-18 13:20:21 +00:00

9.7 KiB
Raw Blame History

Umsetzungsplan — Audit-Formular (Laravel) + Cookie-/Datenschutz-Anpassung

Kontext: Die statische markemacht.de wurde in die Laravel-App integriert. Zwei offene Punkte: (1) das Anfrage-/Audit-Formular ist nach der Migration tot und muss als Laravel-Feature wieder funktionieren, (2) Laravel setzt jetzt System-Cookies — der Hinweis „Keine Cookies" und die Datenschutzerklärung müssen ehrlich werden.

Dieses Dokument ist lebend: Es wird nach jedem Checkpoint aktualisiert. Wer die Arbeit (auch an einem anderen Tag) wieder aufnimmt, liest zuerst 📍 Aktueller Stand und macht beim ersten offenen Checkpoint weiter. Jeder Checkpoint ist so geschnitten, dass der Code danach in sich konsistent ist (Tests grün, nichts halb-fertig).

📍 Aktueller Stand (immer zuerst lesen)

  • Phase: ✅ 1 + 2 abgeschlossen.
  • Zuletzt erledigt: Phase 2 komplett & verifiziert — mm-wirkung-Cookie entfernt (JS+Blade, aus Build bestätigt), Footer „DSGVO-konform · keine Weitergabe", Datenschutz neu, 61/61 Tests grün, Build neu (markemacht-NNJhNDv3.js).
  • Als Nächstes: Phase 3 (Klarheits-Check) — eigener Plan/PR, separat. ODER offene Commit-Grenze klären.
  • Offen (Entscheidung User): Commit-Grenze. Branch ist komplett WIP/uncommittet; die Phase-1/2- Dateien sind NICHT separat committet, um die laufende Integration nicht zu fragmentieren.
  • Branch: feat/markemacht-laravel-migration
  • Wiederaufnahme: Diesen Block lesen → ersten offenen [ ]-Checkpoint suchen → dort „Verifikation" am Ende ausführen, um den Ist-Zustand zu bestätigen, dann weiterarbeiten.

Gesperrte Entscheidungen (nicht mehr offen)

  • Audit-Formular wird Livewire-SFC web.audit-form (Projekt-Konvention: Single-File-Component mit ⚡-Präfix unter resources/views/components/web/⚡audit-form.blade.php, nicht class-based). Tag im Markup: <livewire:web.audit-form />. Modal-Chrome (öffnen/schließen/Fokus in markemacht.js) bleibt Vanilla-JS unverändert.
  • Mailversand über Mailable + config/mail.php. Lokal: Mailpit (Mutterschiff). Echte SMTP-Creds kommen später in die Server-.env — Code liest nur aus config('mail').
  • Klarheits-Check ist nicht Teil dieses Plans (eigenes Feature/PR, Controller-basiert).
  • Cookie-Strategie: nur technisch notwendige Cookies (*_session, XSRF-TOKEN). mm-wirkung-Cookie wird entfernt → localStorage-only. Kein Cookie-Banner (kein Rechtsrat).
  • Footer-Text statt „Keine Cookies": „DSGVO-konform · keine Weitergabe".

Fortschritt (Überblick)

Phase 1 — Audit-Formular funktionsfähig (Livewire)

  • CP 1.1 Mail-Fundament: AuditAnfrage-Mailable + Mail-View, Config/ENV geprüft
  • CP 1.2 Livewire-Komponente AuditForm (Validierung, Honeypot, Throttle, Versand)
  • CP 1.3 Modal-Markup auf <livewire:web.audit-form /> umstellen; Livewire-Assets sicherstellen
  • CP 1.4 Tests (Mail::fake, Validierung, Honeypot, Throttle) + Pint — 58/58 grün
  • CP 1.5 Manuelle Verifikation in Mailpit (Commit: an User-Commit-Grenze gekoppelt)

Phase 2 — Cookies & Datenschutz ehrlich

  • CP 2.1 mm-wirkung-Cookie entfernen (JS + Blade-Fallback) → localStorage-only
  • CP 2.2 Footer-Text „Keine Cookies" → „DSGVO-konform · keine Weitergabe"
  • CP 2.3 Datenschutz: Cookie-Absatz neu (technisch notwendige Cookies) + Aussage Datenweitergabe
  • CP 2.4 Tests (Footer-Text, Datenschutz-Inhalt) + Pint — 61/61 grün, Build neu

Phase 3 — (separat, nur notiert)

  • Klarheits-Check: Blade + JS + POST /klarheits-check/auswerten (Anthropic-Proxy), inkl. KI-Datenschutz-Absatz. Eigener Plan/PR.

Phase 1 — Audit-Formular (Detail)

Altes Verhalten (Referenz): _markemacht.de/assets/php/send-anfrage.php — POST, Felder name, email, message, privacy (Pflicht-Checkbox), Honeypot company/url, Versand per PHPMailer/SMTP, JSON-Antwort {ok, message}. Empfänger/Betreff aus config.php.

CP 1.1 — Mail-Fundament

  • php artisan make:mail AuditAnfrage --markdown=mail.audit-anfrage (oder plain Blade-View)
  • Mailable: Felder name, email, message; Reply-To = Absender; Subject „Neue Anfrage über markemacht.de"; Empfänger aus config (z. B. config('mail.from') oder neue config('marketing.anfrage_empfaenger')).
  • Empfänger-Adresse: entscheiden, wo sie herkommt (ENV MARKETING_ANFRAGE_TO, Default info@markemacht.de). In config/ ablegen, nicht hardcoden.
  • Verifikation: php artisan test läuft weiter grün; Mailable-Klasse existiert.
  • Wiederaufnahme-Notiz (erledigt 2026-06-18): Mailable App\Mail\AuditAnfrage (ctor: anfrageName, anfrageEmail, anfrageMessage; replyTo = Absender; Subject „Neue Anfrage über markemacht.de"). View resources/views/mail/audit-anfrage.blade.php. Empfänger: config('marketing.anfrage_empfaenger') ← MARKETING_ANFRAGE_TO, Default info@markemacht.de (neue Datei config/marketing.php). Render + Inhalt verifiziert.

CP 1.2 — Livewire-Komponente

  • php artisan make:livewire Web/AuditForm (Livewire-4-Konvention im Projekt prüfen)
  • Properties + Rules: name required, email required/email, message required, privacy accepted; Honeypot company/url (müssen leer sein).
  • submit(): Honeypot-Check (still „erfolgreich" bei Befüllung), Validierung, RateLimiter (z. B. 3 Anfragen / 10 Min pro IP), Mail::to(...)->send(new AuditAnfrage(...)), Erfolg → $this->dispatch('audit-sent') (das hört markemacht.js:139 bereits), Felder leeren, Status-Property setzen.
  • View resources/views/livewire/web/audit-form.blade.php: 1:1 die bestehenden Felder/Klassen aus footer.blade.php übernehmen (Designsystem unverändert), wire:model, wire:submit, @error, wire:loading, aria-live-Status.
  • Verifikation: Komponente rendert isoliert (Livewire::test).
  • Wiederaufnahme-Notiz: (Throttle-Limits, Event-Name, Validierungsregeln dokumentieren)

CP 1.3 — Einbau ins Modal

  • In resources/views/web/partials/footer.blade.php den <form data-audit-form …>-Block (Zeilen ~45–77) durch <livewire:web.audit-form /> ersetzen. Hülle [data-audit-form-panel] behalten oder in die Komponente ziehen — Modal-Chrome bleibt.
  • Sicherstellen, dass Livewire-Assets auf Marketing-Seiten geladen werden (Default-Auto-Inject prüfen; ggf. @livewireScripts/@livewireStyles ins Marketing-Layout). Achtung: vorher lud die Marketing-Seite KEIN Livewire — hier genau testen (Konsole auf Fehler prüfen).
  • Verifikation: Seite /audit und Footer-Modal öffnen, Formular sichtbar, keine JS-Fehler.
  • Wiederaufnahme-Notiz: (ob Layout angepasst werden musste)

CP 1.4 — Tests

  • Feature-/Livewire-Test in tests/Feature/Web/: erfolgreicher Versand (Mail::fake, assertSent), Validierungsfehler, Honeypot (kein Versand, aber „ok"), Throttle.
  • php artisan test --compact --filter=Audit
  • vendor/bin/pint --dirty
  • Verifikation: alle neuen Tests grün, Gesamt-Suite grün.

CP 1.5 — Manuell + Commit

  • Lokal echtes Absenden → Mail erscheint in Mailpit.
  • Commit: feat(marketing): Audit-Anfrageformular als Livewire-Komponente.
  • Verifikation: git log zeigt Commit; Arbeitsbaum sauber bzgl. Phase 1.

Phase 2 — Cookies & Datenschutz (Detail)

CP 2.1 — mm-wirkung-Cookie entfernen

  • resources/js/web/markemacht.js:28 (document.cookie = …mm-wirkung…) entfernen.
  • resources/views/web/layouts/marketing.blade.php:53 Cookie-Fallback im Inline-Script entfernen (localStorage genügt, läuft vor erstem Paint).
  • npm run build nötig (JS/Blade-Asset) — User bitten oder ausführen.
  • Verifikation: Theme-Umschalter funktioniert weiter; im DevTools-Application-Tab kein mm-wirkung-Cookie mehr, nur localStorage.

CP 2.2 — Footer-Text

  • resources/views/web/partials/footer.blade.php:6 „Keine Cookies" → „DSGVO-konform · keine Weitergabe".
  • Verifikation: Footer zeigt neuen Text.

CP 2.3 — Datenschutzerklärung

  • resources/views/web/datenschutz.blade.php:225-226: „verwendet keine Cookies" ersetzen durch Absatz „Technisch notwendige Cookies": markemacht_session + XSRF-TOKEN, Zweck (Bereitstellung/Absicherung der Formulare), Art. 6 Abs. 1 lit. f DSGVO / § 25 Abs. 2 TTDSG, keine Einwilligung nötig, kein Tracking.
  • localStorage-Absatz (228–233) bleibt korrekt → behalten.
  • Aussage zur Datenweitergabe ergänzen/prüfen (Umami self-hosted, keine Dritten) — passt zur Footer-Aussage und zum bestehenden Umami-Absatz (285+).
  • Verifikation: Datenschutzseite konsistent, keine Aussage „keine Cookies" mehr.

CP 2.4 — Tests + Commit

  • Test in tests/Feature/Web/: Footer enthält neuen Text / nicht mehr „Keine Cookies"; Datenschutz enthält „Technisch notwendige Cookies".
  • php artisan test --compact + vendor/bin/pint --dirty
  • Commit: feat(marketing): Cookie-Hinweis & Datenschutz an Laravel-Integration angepasst.
  • Verifikation: Suite grün, Commit gesetzt.

Changelog (Arbeitsprotokoll)

Datum Checkpoint Ergebnis / Notiz
2026-06-18 Setup Plan angelegt, Entscheidungen gesperrt, Footer-Text = „DSGVO-konform · keine Weitergabe".
2026-06-18 Phase 1 Mailable AuditAnfrage + Config marketing.anfrage_empfaenger, Livewire-SFC web.audit-form, Modal-Einbau, Tests, Mailpit-E2E.
2026-06-18 Phase 2 mm-wirkung-Cookie raus (localStorage-only), Footer-Hinweis, Datenschutz „Technisch notwendige Cookies", Tests, Build.