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>

docs/Echte öffentliche Unterseiten.md

@@ -2,15 +2,43 @@
 > der oeffentlichen Strecke. Welcher Punkt bereits umgesetzt ist, ist
 > jeweils mit einer kurzen IST-Notiz markiert.
 
+> **Update 16.06.2026 — Editorial-Relaunch & Ausgaben-Routing.**
+> Die oeffentliche Strecke wurde auf ein gemeinsames Editorial-Design
+> (Komponenten `x-web.site-header` / `x-web.site-footer`, Design-Tokens in
+> `resources/css/web/shared-styles.css`) umgestellt und auf ein
+> Ausgaben-Praefix `/{edition}/…` (Sprache `de` | `en`) gehoben.
+>
+> - **Routing**: Neue Middleware `app/Http/Middleware/SetEdition.php` liest
+>   die Ausgabe aus dem ersten URL-Segment, setzt Locale + `URL::defaults`.
+>   `routes/web.php` gruppiert alle oeffentlichen Routen unter `/{edition}`.
+>   `/` leitet auf die Default-Ausgabe (`/de`) um; Legacy-`.html`-URLs werden
+>   per 301 auf die neuen Pfade gemappt. Baseline-Default in
+>   `AppServiceProvider` fuer Route-Generierung ausserhalb von HTTP-Requests.
+> - **Neue URL-Schemata**: Detailseite `/{edition}/press-release/{slug}`
+>   (Route `release.detail`), Kategorie `/{edition}/category/{slug}`
+>   (Route `kategorie`).
+> - **Ausgabe = Sprache**: DE/EN-Umschalter im Header (Region-/CH-/AT-Auswahl
+>   entfernt). `EditorialClock` (`app/Support/EditorialClock.php`) und die
+>   Livewire-Komponenten sind sprachdynamisch.
+> - **Rubriken-Navigation** statt Uebersichtsseite: Helper
+>   `app/Support/CategoryNavigation.php` liefert die Top-Rubriken der Ausgabe;
+>   Header/Footer verlinken direkt auf die Kategorieseiten. Die alte
+>   `web/kategorien.blade.php` + Route wurden entfernt (Legacy-301).
+> - **Tests**: `tests/Feature/Web/` deckt Edition-Routing, Kategorie-Seite,
+>   Kategorie-Navigation, Detailseite, Veroeffentlichen, Suche und den
+>   EditorialClock ab.
+
 Das sind die Seiten, die eigene URLs brauchen, weil sie verlinkbar sein müssen, SEO-Wert haben oder direkt von extern angesteuert werden.
 
 #### Inhalts-Seiten (Lese-Erfahrung)
 
 **1. Pressemitteilungs-Detailseite** – `/p/[slug]` oder `/pressemitteilung/[id]` Die wichtigste Seite überhaupt. Jede einzelne PM bekommt eine eigene Seite. Hier landen 90% des Traffics aus Google, Newsletter und Social Shares.
 _IST 21.05.2026_: umgesetzt als `resources/views/web/release-detail.blade.php` (Route `release.detail`, URL `/release/{slug}`). Das URL-Schema weicht vom Plan ab, ist aber konsistent über alle Themen.
+_IST 16.06.2026_: im Editorial-Design neu aufgebaut, echte Daten (Firma, Kontakte, Bilder, verwandte Meldungen). Neue URL `/{edition}/press-release/{slug}`; Legacy-URLs per 301. Test: `tests/Feature/Web/ReleaseDetailTest.php`.
 
 **2. Branchen-Übersichten** – `/branche/[slug]` Zum Beispiel `/branche/energie-klima`, `/branche/finanzen`. Aggregierte Sicht auf alle PMs einer Branche, mit Sub-Filtern. Das sind deine SEO-Goldgruben (jede Branche eine ranking-fähige Landing Page).
 _IST 21.05.2026_: umgesetzt (`web/kategorie.blade.php`, `web/kategorien.blade.php`).
+_IST 16.06.2026_: `web/kategorie.blade.php` im Editorial-Design mit echten Daten (Top-Meldung, Feed, Sub-/verwandte Branchen, Stats, Newsrooms). Neue URL `/{edition}/category/{slug}`. Es gibt **keine** Gesamt-Uebersicht mehr — die Header-/Footer-Navigation fuehrt direkt auf die Rubrik (`CategoryNavigation`); `web/kategorien.blade.php` + Route entfernt (Legacy-301). Tests: `CategoryPageTest`, `CategoryNavigationTest`.
 
 **3. Regionen-Übersichten** – `/region/[slug]` `/region/deutschland`, `/region/bayern`, `/region/oesterreich`. Analog zu Branchen, regional gefiltert.
 _IST 21.05.2026_: noch nicht umgesetzt.
@@ -20,6 +48,7 @@ _IST 21.05.2026_: Layout vorhanden (`web/newsrooms.blade.php`), Daten-Anbindung
 
 **5. Such-Ergebnisseite** – `/suche?q=...` Volltextsuche mit Filtern (Erweiterte Suche schreibt in URL-Parameter, dadurch teilbar/bookmarkbar).
 _IST 21.05.2026_: Layout vorhanden (`web/suche.blade.php`), Volltextsuche noch nicht aktiv.
+_IST 16.06.2026_: aktive Suche umgesetzt. `web/suche.blade.php` im Editorial-Design + Volt-Komponente `livewire/web/search.blade.php`: Suche ueber Titel/Untertitel/Text/Keywords sowie Firmenname und Rubrik-Name, Rubriken-Filter, Sortierung (Neueste/Aelteste/Meistgelesen), Pagination. URL-Parameter `q`, `category`, `sort` (teilbar/bookmarkbar); portal-/sprachsensitiv. Test: `tests/Feature/Web/SearchPageTest.php`.
 
 **6. Tag-/Themen-Seite** – `/thema/[slug]` _(optional, später)_ Nicht im ersten Release zwingend, aber sehr SEO-wirksam für aktuelle Themen ("Künstliche Intelligenz", "Lieferkettengesetz", "Energiekrise"). Würde ich datengetrieben aus den meistverwendeten Tags generieren lassen.
 _IST 21.05.2026_: nicht umgesetzt (bewusst spaeter).
@@ -28,6 +57,7 @@ _IST 21.05.2026_: nicht umgesetzt (bewusst spaeter).
 
 **7. Pressemitteilung einreichen / Veröffentlichen** – `/veroeffentlichen` Die Conversion-Landingpage für neue Publisher. Erklärt Mehrwert, zeigt Tarife, Editor-Vorschau. Dahinter der eigentliche Editor (im User-Bereich).
 _IST 21.05.2026_: Landing-Seite vorhanden (`web/veroeffentlichen.blade.php`). Editor-Strecke im User-Bereich ist umgesetzt (siehe Phase 7).
+_IST 16.06.2026_: Landing-Seite im Editorial-Design neu aufgebaut, echte Kennzahlen (Archiv-Gesamt, heute veroeffentlicht/in Pruefung, aktive Newsrooms, Beispiel-Mitteilung). Einreichung verweist auf den zentralen Publisher-Bereich. Test: `tests/Feature/Web/VeroeffentlichenPageTest.php`.
 
 **8. Tarife & Preise** – `/preise` _(oder als Modal aus mehreren Stellen aufrufbar)_ Da Tarife auch im Modal aus dem CTA aufgerufen werden, ist die Frage: brauchen wir die Seite? Antwort ja, weil SEO ("Pressemitteilung veröffentlichen Preise" ist eine wichtige Suche) und weil sie verlinkbar sein muss aus AGB, Footer, Mediadaten.
 _IST 21.05.2026_: Layout vorhanden (`web/preise.blade.php`), echte Tarife noch nicht hinterlegt (Tarif-Modul siehe `Presseportal – Konzept für Relaunch.md` Abschnitt 8).

docs/user-admin/Admin-User.md

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