gitmedia/presseportale
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
presseportale/dev/frontend/hub-flux/03-WEITERE-PHASEN.md

12 KiB
Raw Blame History

Weitere Phasen — Outline

Übersicht über Phasen 2–6. Diese werden detailliert ausgearbeitet, sobald Phase 0+1 abgenommen sind. Jede Phase bekommt ein eigenes 0X-PHASE-N-NAME.md, wenn sie aktiv wird.

Phase 2 — Customer-Dashboard auf Mockup-Stil

Status: ✅ abgeschlossen (de facto in Phase 1 + verfeinert in 4J) · Aufwand: ~½ Tag · Risiko: niedrig

Während der Phase-1-Migration wurden Page-Header, KPI-Reihe, 2-Spalten-Grids, <x-portal.stat-card>, <x-portal.hint-card> und Brand-Bridge-Dark-Card bereits umgesetzt. Phase 4J hat die Recent-PM-Liste mit Portal-Pills

  • PM-ID-Sub auf den finalen 4H/4I-Pattern-Stand gebracht. Match zum Mockup ≥ 95 %.

Ziel

livewire/customer/dashboard.blade.php matched das Mockup User Dashboard presseportale.html zu ≥ 90 %.

Bausteine

  • Page-Header mit „Mein Dashboard" + Begrüßung + Firma-zugeordnet-Pille
  • KPI-Reihe (4 Stat-Cards mit linkem Farb-Strip)
    • Gesamt (Hub-Blau-Strip)
    • Veröffentlicht (Grün-Strip, is-ok)
    • In Prüfung (Bernstein-Strip, is-warn)
    • Entwürfe (Grau-Strip, is-muted)
  • 2-Spalten-Grid:
    • Links: Empty-State / Liste „Meine letzten Pressemitteilungen"
    • Rechts: „Datenqualität" mit Progress-Bars (Profil-Vollständigkeit, Rechnungsadresse)
  • Unten:
    • Links: Firmen-Slots
    • Rechts: Brand-Bridge-Dark-Card (presseecho + businessportal24)

Neue Blade-Components

  • <x-portal.stat-card> — Stat-Card mit Slot + Strip-Variante
  • <x-portal.hint-card> — Datenqualitäts-Hint mit Icon + Progress-Bar
  • <x-portal.bridge-card> — Dunkle Brand-Bridge-Card

→ Diese landen in resources/views/components/portal/.

Phase 3 — Admin-Dashboard konsistent

Status: ✅ abgeschlossen (in Phase 1 + 4J) · Aufwand: ~½ Tag · Risiko: niedrig

Admin-Dashboard nutzt seit Phase 1 dasselbe Vokabular wie das Customer-Dashboard: Page-Header, 5-KPI-Reihe mit <x-portal.stat-card>, 2-Spalten-Grid (Recent + Pending Reviews), Newsletter panel-warm, Quick-Actions-Grid, Footer. Phase 4J hat Portal-Pills, PM-ID-Sub und Inline-Action „Prüfen →" mit is-row-warn-Tinting für die Review-Queue ergänzt.

Phase 4 — Listen-/Detail-Pages durchgehen

Status: ✅ komplett abgeschlossen (4A–4J) · Aufwand: ~3–5 Tage gesamt · Risiko: niedrig

Alle 10 Sub-Päckchen (4A–4J) sind grün, Build + Pint sauber, alle relevanten Tests bestehen (230/231 gesamt — der eine Fail ist der pre-existing ApiDocumentationTest ohne Bezug zur UI-Migration). Das gesamte Backend (Admin + Customer) nutzt damit dieselbe Design-Sprache: Page-Header mit Eyebrow/Badge/Subtitle, <x-portal.stat-card>-KPI-Reihen, article.panel als Container, flux:table mit Hub-Padding

  • Sortierung, flux:card nur wo Test-Verträge sie noch brauchen, sowie die Mockup-Patterns aus 4H/4I/4J (Saved-Views-Tabs, Active-Chips, Portal-Pills, Inline-Actions, Row-Tinting, 3-stufige Empty-States).

Ziel

Alle Volt-Pages im Admin- und Customer-Bereich nutzen denselben Hub-Stil.

Vorgehen

  • Pro Page: 15–30 min
  • In Päckchen geteilt:
    • 4A = Press-Releases Listen (Admin + Customer) — ✅ abgeschlossen siehe 07-PHASE-4A-PRESS-RELEASES-LISTEN.md
    • 4B = Press-Releases Detail/Show (Admin + Customer) — ✅ abgeschlossen siehe 08-PHASE-4B-PRESS-RELEASES-DETAIL.md
    • 4C = Press-Releases Forms (create/edit, Admin + Customer) — ✅ abgeschlossen siehe 09-PHASE-4C-PRESS-RELEASES-FORMS.md
    • 4D = Companies (admin.companies.*) — ✅ abgeschlossen siehe 10-PHASE-4D-COMPANIES.md
    • 4E = Profile/Settings (settings.*, customer.profile, customer.security) — ✅ abgeschlossen siehe 11-PHASE-4E-PROFILE-SETTINGS.md
    • 4F = Restliche Admin-Bereiche (contacts, categories, presets, footer-codes, users, roles, newsletter, reports, invoices, coupons, payments, portal-switcher) — ✅ abgeschlossen siehe 13-PHASE-4F-ADMIN-REST.md
    • 4G = Restliche Customer-Bereiche (invoices, tokens, bookings, company-switcher, me/press-kits/*) — ✅ abgeschlossen siehe 12-PHASE-4G-CUSTOMER-PORTAL.md
    • 4H = Customer „Meine Pressemitteilungen" auf Mockup-Stil (Counter-Strip, Saved-Views-Tabs, Filter-Chips, Active-Chips, Portal-Pills, Inline-Actions, Row-Tint, 3-fach-Empty-State, Status-Aktionen-Legende) — ✅ abgeschlossen siehe 14-PHASE-4H-PRESS-RELEASES-MOCKUP.md
    • 4I = Admin „Pressemitteilungen" — Mockup-Patterns übertragen (Saved-Views-Tabs, Active-Chips, Portal-Pills, Row-Tint, Inline-Actions als Modal-Trigger, reduzierte Spalten, 2-stufiger Empty-State) — ✅ abgeschlossen siehe 15-PHASE-4I-ADMIN-PRESS-RELEASES.md
    • 4J = Dashboard-PM-Listen mit 4H/4I-Patterns (Portal-Pills, PM-ID-Sub, Customer + Admin Dashboard, Inline-Action „Prüfen →" für Admin-Review-Queue mit is-row-warn Tinting) — ✅ abgeschlossen siehe 16-PHASE-4J-DASHBOARD-LISTS.md

Was geändert wird

  • Page-Header-Struktur (Eyebrow + H1 + Subtitle + Aktions-Bar)
  • Filter-Bars werden Hub-konform gestylt
  • flux:table-Header bekommen Eyebrow-Optik
  • Form-Felder bleiben FluxUI, aber mit Hub-Tokens

Was nicht geändert wird

  • Logik / Volt-Methoden
  • Datenbank / Models

Phase 5 — Dark Mode konsistent

Status: ✅ abgeschlossen · Aufwand: ~½ Tag (Großteil der Arbeit war Vorbereitung in Phase 0–4) · Risiko: niedrig

Tokens, Switcher und alle Custom-CSS-Komponenten waren bereits token-basiert vorbereitet — shared/design-tokens.css hat einen kompletten .dark { … }-Block (Z. 182–248) mit allen Surfaces, Hub/Bernstein-Akzenten, Ink-Skala, Status-Farben, Schatten und color-scheme: dark. hub-components.css ist zu 100 % token-basiert und schaltet automatisch um. FluxUI's @fluxAppearance ist in beiden Head-Partials integriert, Switcher liegt im User-Menü (Desktop + Mobile) sowie in settings/appearance.blade.php. Bei der Inventur fiel nur ein latenter Bug auf (--color-ink-deep-Token existiert nicht, in customer/tokens.blade.php auf --color-panel-dark-2 umgestellt). QR-Code in customer/security.blade.php behält bewusst bg-white in beiden Modi (Scan-Tauglichkeit), klarstellender Kommentar ergänzt.

Siehe 17-PHASE-5-DARK-MODE.md für Details.

Quelle

dev/frontend/tailwind_v3/User Dashboard presseportale Dark.html hat alle Dark-Tokens bereits vorgegeben — alle Werte sind in design-tokens.css übernommen.

Was geliefert wird

  • Settings → Erscheinung → „Dunkel" schaltet Portal um
  • Settings → Erscheinung → „System" folgt OS-Präferenz
  • Switcher zusätzlich direkt im User-Menü (Sidebar + Mobile)
  • Sidebar, Topbar, Dashboards, Listen, Forms — alles schaltet automatisch über Token-Cascade um
  • panel-dark bleibt KONSTANT dunkel (Brand-Bridge-Card)
  • --color-accent-warm bleibt KONSTANT Bernstein (Hint-Cards)
  • Hub-Landing und Hub-Auth bleiben Light (kein @fluxAppearance im Web-Build)

Phase 6 — Auth-Cleanup

Status: ✅ abgeschlossen · Aufwand: ~30 min · Risiko: niedrig

Hub-Auth bleibt eigenständig (auf Web-Build mit dem pressekonto-Layout), weil Hub-Atmosphäre + Light-Bundle als Trade-off bewusst gewollt sind. Die ungenutzten Starter-Kit-Layouts wurden entfernt: auth/simple, auth/split, auth/card, der Wrapper auth.blade.php, das alternative app/header.blade.php sowie die Debug-Views livewire/auth/login-simple und test-simple. Damit gibt es keine hardcoded class="dark"-Reste mehr, die Phase 5 hätten torpedieren können. Doku-Beispiel in _docs/FORTIFY-SANCTUM-SETUP.md auf components.layouts.auth.pressekonto umgestellt. CSS-Bundle ist dabei sogar ~2.4 KB kleiner geworden.

Siehe 18-PHASE-6-AUTH-CLEANUP.md für die Inventur.

Optional für später (NICHT Teil von Phase 6)

Eine echte Auth-Konsolidierung (Hub-Auth-CSS in den Portal-Build ziehen, Web-Build nur für die Landing-Pages behalten) wäre denkbar, aber:

  • Hub-Atmosphäre (Konzentrische Kreise, Hub-Grid) ist visuell stark
  • Hub-Auth ist leichtgewichtig (kein FluxUI im Bundle)
  • Aktueller Stand funktioniert sauber

→ keine Action notwendig, bleibt offen.

Gesamt-Status (Stand 2026-05-29)

Phase Inhalt Status
0 Hub-Auth (Login/Register) im Hub-Stil ✅
1 Portal-Migration (Tokens, FluxUI-Overrides, Sidebar/Topbar, App-Shell, Dark-Switch im User-Menü) ✅
2 Customer-Dashboard auf Mockup-Stil ✅ (in P1, verfeinert in 4J)
3 Admin-Dashboard konsistent ✅ (in P1, verfeinert in 4J)
4 Listen/Detail durchgehen (4A–4J) ✅ komplett
5 Dark Mode konsistent ✅ abgeschlossen
6 Auth-Cleanup ✅ abgeschlossen
7 Press-Release-Form-Refactor (7A–7F) ✅ abgeschlossen (19-PHASE-7-…)

Phase 4 — Sub-Päckchen im Detail

ID Bereich Plan-Doc
4A Press-Releases Listen (Admin + Customer) 07-PHASE-4A-…
4B Press-Releases Detail/Show 08-PHASE-4B-…
4C Press-Releases Forms (create/edit) 09-PHASE-4C-…
4D Companies (Admin) 10-PHASE-4D-…
4E Profile/Settings (Admin + Customer) 11-PHASE-4E-…
4F Restliche Admin-Bereiche (contacts, categories, presets, footer-codes, users, roles, newsletter, reports, invoices, coupons, payments, portal-switcher) 13-PHASE-4F-…
4G Restliche Customer-Bereiche (invoices, tokens, bookings, company-switcher, press-kits) 12-PHASE-4G-…
4H Customer „Meine Pressemitteilungen" Mockup-Stil (Counter-Strip, Saved-Views, Filter-/Active-Chips, Portal-Pills, Inline-Actions, Row-Tint, 3-stufiger Empty-State, Aktionen-Legende) 14-PHASE-4H-…
4I Admin „Pressemitteilungen" — Mockup-Patterns übertragen 15-PHASE-4I-…
4J Dashboard-PM-Listen mit 4H/4I-Patterns 16-PHASE-4J-…

Nächste sinnvolle Schritte (Priorität)

Die hub-flux-Roadmap ist mit Phase 6 vollständig abgeschlossen. Alle weiteren Themen sind eigene Initiativen.

✅ Abgeschlossen — Phase 7 (Press-Release-Form-Refactor): Mockup User Neue Mitteilung presseportale.html auf den Customer-Create/Edit-Flow übertragen. Plan-Doc: 19-PHASE-7-PRESS-RELEASE-FORM.md. Alle Päckchen umgesetzt: 7A (Migrations: subtitle/boilerplate_override/scheduled_at/ embargo_at + attachments-Tabelle + companies.boilerplate) → 7B (flux:editor + PressReleaseHtmlSanitizer via mews/purifier) → 7C (Customer-Create-UI, 2-Spalter mit sticky Settings-Sidebar) → 7D (Customer-Edit-UI) → 7E (Anhänge-Manager) → 7F (Scheduling/Embargo + press-releases:publish-scheduled Command + 5-Min-Scheduler). Admin-Create/Edit ziehen optisch mit; Scheduling-UI bleibt Customer-seitig. Detail siehe PROGRESS.md (Eintrag 2026-05-22).

Offene Folge-Initiativen

  1. Manueller Dark-Mode Smoke-Test: Im Browser User-Menü → Erscheinung → „Dunkel" und durch die Hauptseiten klicken (Dashboard, Listen, Detail, Security mit QR, Tokens). Erwartung: Lesbar + konsistent. Kleine Polish-Runde, falls visuelle Auffälligkeiten.

  2. Admin-Create/Edit nachziehen: Die Admin-PM-Forms haben das Phase-7-Layout optisch übernommen, aber Scheduling/Embargo-UI ist bewusst Customer-seitig geblieben. Bei Bedarf als kleines Folge-Päckchen für Admins ergänzen.

  3. Web-Frontend-Block (eigenständig, NICHT Teil von Phase 1–6): Die noch ungenutzten Mockups Startseite Tailwind.html, Startseite presseecho Tailwind.html, Branchenseite Tailwind.html, Detailseite Tailwind.html, Veröffentlichen Tailwind.html sind Public-Facing-Pages der beiden Portale (businessportal24 + presseecho), nicht Portal/Backend. Würde eine eigene Roadmap bekommen, weil andere Build-Pipeline (vite.web.config.js), andere Komponenten und ein ganz anderer Stil-Stack (Source-Serif-Headlines, Brand-orange für businessportal24).