Frontend: Editorial-Relaunch der öffentlichen Strecke + Ausgaben-Routing
Öffentliche Seiten auf gemeinsames Editorial-Design (x-web.site-header/-footer,
Design-Tokens) und Ausgaben-Präfix /{edition}/ (de|en) umgestellt.
- Routing: neue Middleware SetEdition (Locale + URL::defaults), /{edition}-Gruppe
in routes/web.php, Root-Redirect auf /de, 301 für Legacy-.html-URLs,
Baseline-Default in AppServiceProvider.
- Neue URL-Schemata: /{edition}/press-release/{slug}, /{edition}/category/{slug}.
- Ausgabe = Sprache: DE/EN-Umschalter (Region/CH/AT entfernt); EditorialClock
und Livewire-Komponenten sprachdynamisch.
- Detail-, Kategorie- und Veröffentlichen-Seite mit echten Daten neu aufgebaut.
- Suche aktiviert: Volt-Komponente livewire/web/search (Titel/Text/Keywords +
Firma + Rubrik, Filter, Sortierung, Pagination, URL-Parameter q/category/sort).
- Rubriken-Navigation statt Übersichtsseite: Helper CategoryNavigation;
web/kategorien.blade.php + Route entfernt (Legacy-301).
- Tests: Edition-Routing, Kategorie-Seite/-Navigation, Detail, Veröffentlichen,
Suche, EditorialClock. Doku in "Echte öffentliche Unterseiten.md" aktualisiert.
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
parent
a0547208d3
commit
253141c6dc
64 changed files with 4457 additions and 2971 deletions
|
|
@ -418,11 +418,14 @@ Im Header die Rolle als Badge zeigen, damit der User immer weiß, was er darf, o
|
|||
## Offene Designentscheidungen
|
||||
|
||||
**1. Firmenwechsel-Bestätigung** Wenn ein User im Firmen-Detail arbeitet und über den Switcher die Firma wechselt – sofort wechseln oder Warnung „ungespeicherte Änderungen"? Ich würde Standard-Browser-Verhalten beibehalten (`beforeunload` bei dirty forms), kein eigener Dialog.
|
||||
#Ja Ohne Dialog.
|
||||
|
||||
**2. Firma deaktivieren vs. löschen** Im Datenmodell ist Aktiv/Inaktiv vorhanden. Echtes Löschen ist heikel wegen verknüpfter PMs, Rechnungen, Kontakte. Ich würde dem User **nur** Deaktivieren anbieten – echtes Löschen läuft über Support-Anfrage. Senkt deine Risiken bei DSGVO-Konflikten.
|
||||
#Ja Firmen nur dekativieren
|
||||
|
||||
**3. Owner-Übertragung** „Firma übertragen" ist ein sensibler Vorgang. Ich würde einen eigenen Wizard mit E-Mail-Bestätigung beim neuen Owner verlangen (ähnlich GitHub-Repo-Transfer). Macht den Punkt komplexer, aber sauber.
|
||||
#ja genau so soll es gemacht werden, wird allerdings oft nach den Relaunch verschoben.
|
||||
|
||||
**4. Pressekontakt-Zuordnung beim PM-Erstellen** Beim Anlegen einer neuen PM: Sollen alle Pressekontakte der Firma automatisch zugeordnet werden, oder muss der User explizit auswählen? Ich tendiere zu „alle vorausgewählt, abwählbar" – gibt dem User eine Voreinstellung, die in 90 % der Fälle stimmt.
|
||||
|
||||
Ja Würde ich so machen die meisten haben eh nur einen oder keine Pressekontakt.
|
||||
---
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue