-- "Alle Pressemitteilungen werden geprüft..."
```
#### Volt-Komponenten (reaktiv, isolierter State)
```
-- Auto-refresh alle 30s, Polling
-- 3 Top-Meldungen, auto-rotate mit Alpine
-- Suche im Header
-- "Alle · Heute · Diese Woche" Tabs
-- Newsroom-Sidebar mit "heute aktiv" Polling
-- Live-Werte mit ± Indikatoren
-- Termine-Karussell mit Wochen-Navigation
```
#### Klassisches Livewire (komplex, services)
```
PressSubmissionForm -- Mehrstufige Einreichung (auf Hub)
NewsroomManager -- Profil-Verwaltung (auf Hub)
AdminReviewQueue -- Redaktions-Tool (auf Hub)
```
Auffällig: die **Brand-Portale brauchen kaum klassisches Livewire**. Das ist konsistent zur Architektur aus Update 3 – Brand-Portale sind primär Lese-Oberflächen, der State liegt im Hub.
## 5. Brand-Differenzierung in Komponenten
Drei Mechanismen, in aufsteigender Eingriffstiefe:
### 5a. Konfiguration über Brand-Config
Der einfachste Fall: eine Komponente verhält sich anders je nach Brand-Konfiguration. (Beispiel)
siehe: config/domains.php
```php
return [
'name' => 'businessportal24',
'tagline' => 'Pressemitteilungen · DACH',
'press_item_layout' => 'timeline', // vs. 'topic'
'show_market_ticker' => true,
'show_branchen_index' => true,
'hero_variant' => 'top-meldung', // vs. 'topic-cluster'
'rubriken' => ['Wirtschaft', 'Technologie', /* ... */],
];
return [
'name' => 'presseecho',
'tagline' => 'Branchen-Pressearchiv',
'press_item_layout' => 'topic',
'show_market_ticker' => false,
'show_branchen_index' => false,
'hero_variant' => 'topic-cluster',
'rubriken' => [/* andere Reihenfolge, andere Schwerpunkte */],
];
```
Komponenten lesen daraus:
```blade
@if($brand->config('show_market_ticker'))
@endif
```
**Das ist die häufigste Form der Differenzierung** – und sie reicht für ~80 % aller Fälle.
### 5b. Slots und Defaults in Komponenten
Wenn eine Komponente strukturell gleich ist, aber Inhalte/Sprache abweichen:
```blade
{{-- resources/views/components/hub/transition-block.blade.php --}}
@props([
'title' => $brand->config('hub_cta.title') ?? 'Pressemitteilung einreichen',
'description' => $brand->config('hub_cta.description'),
'buttonText' => $brand->config('hub_cta.button') ?? 'Zum Publisher-Bereich',
])
```
Brand-Texte stehen in Config, Komponente bleibt eine.
### 5c. View-Override pro Brand (Eskalations-Pfad)
Für die seltenen Fälle, in denen eine Brand wirklich ein anderes Markup braucht: Laravel kann View-Pfade brand-spezifisch erweitern.
```php
// app/Providers/BrandServiceProvider.php
public function boot(): void
{
$this->app['view']->prependLocation(
resource_path("views/themes/{$brand->slug}")
);
}
```
Dann sucht Laravel View-Dateien zuerst unter `resources/views/themes/presseecho/components/press/item.blade.php`, dann unter dem Standard-Pfad. **Nur** für die Komponenten, die wirklich anders sein müssen, wird eine Override-Datei angelegt.
> **Disziplin-Regel:** View-Overrides sind die letzte Eskalationsstufe. Erst versuchen, mit Config + Slots auszukommen. Override-Dateien verdoppeln Wartungsaufwand – jeder Bugfix muss mehrfach gemacht werden.
## 6. Datei-Struktur (Beispiel, siehe akutelle Struktur und optimiere falls nötig )
```
app/
├── Brand/
│ ├── Brand.php # Eloquent Model
│ ├── BrandManager.php # Service, im Container
│ └── BrandResolver.php # Domain → Brand
├── Http/
│ └── Middleware/
│ └── ResolveBrand.php
├── Livewire/
│ ├── Brand/ # Brand-Portal-spezifisch
│ │ ├── AdHocTicker.php
│ │ ├── HeroSlider.php
│ │ └── PressSearch.php
│ └── Hub/ # Hub-spezifisch
│ ├── PressSubmissionForm.php
│ └── NewsroomManager.php
├── View/
│ └── Components/
│ ├── Brand/
│ ├── Press/
│ ├── Hub/
│ ├── Ui/
│ └── Quality/
└── Providers/
└── BrandServiceProvider.php
config/
└── brands/
├── businessportal24.php
├── presseecho.php
└── hub.php
resources/
├── css/
│ ├── app.css # Tailwind base + semantische Tokens
│ └── themes/
│ ├── businessportal24.css # Brand-Tokens (optional separat)
│ └── presseecho.css
├── js/
│ └── app.js
└── views/
├── layouts/
│ ├── brand.blade.php # Brand-Portal-Layout
│ └── hub.blade.php # Hub-Layout
├── components/ # Standard-Komponenten
│ ├── brand/
│ ├── press/
│ ├── hub/
│ ├── ui/
│ └── quality/
├── livewire/ # Volt-Komponenten
│ ├── ad-hoc-ticker.blade.php
│ ├── hero-slider.blade.php
│ └── press-search.blade.php
├── pages/ # Konkrete Seiten-Templates
│ ├── home.blade.php
│ └── veroeffentlichen.blade.php
└── themes/ # NUR Brand-Overrides
└── presseecho/
└── components/
└── ... # nur was wirklich anders ist
```
## 7. Performance-Strategie
Vier konkrete Hebel, die in dieser Reihenfolge ausgeschöpft werden:
**1. Aggressive View-Caching für statisches Markup.** Press-Listen, Newsroom-Sidebars, Statistik-Zeilen können mit Tag-basiertem Cache gepuffert werden. Neue Mitteilung → relevante Tags invalidieren.
```php
Cache::tags(['press_list', "brand.{$brand->slug}"])
->remember('home.aktuelle-meldungen', now()->addMinutes(5), fn() => /* ... */);
```
**2. Volt-Komponenten lazy laden, wo sinnvoll.** Below-the-fold-Komponenten (Branchen-Index, Termine, Newsroom-Liste) als `lazy`:
```blade
```
Sie laden erst beim Scroll, blockieren nicht das initiale Render.
**3. Asset-Pipeline: ein Bundle, alle Brands.** Über die CSS-Variablen-Strategie ist kein Per-Brand-Build nötig. Ein Vite-Build, der für alle Brands gilt. Spart Komplexität und Cache-Invalidierung.
**4. Brand-Resolution cachen.** Die Domain-zu-Brand-Auflösung ist `rememberForever` (siehe Middleware). Cache-Bust nur beim Brand-Update über Model-Observer.
## 8. Migration der Bestands-Inhalte
Quer zu allem oben: die ~100.000 Bestandsmitteilungen sind im neuem System migriert! Drei Punkte, die das Komponenten-Design beeinflussen:
- **`` muss tolerant gegenüber unvollständigen Daten sein.** Alte Mitteilungen haben evtl. keine Lesezeit-Schätzung, keine Branchen-Zuordnung, keine sauberen Bilder. Komponente rendert auch dann sauber.
- **Permalink-Stabilität.** Die alte URL-Struktur muss erhalten bleiben (Strategie-Dokument: Tombstone-Modell). Das ist ein Routing-Thema, kein Komponenten-Thema – aber die Komponenten dürfen keine URLs hardcoden, sondern nur `route()`-Helpers nutzen.
- **Brand-Zuordnung der Bestände.** Wie in Update 3 festgelegt: am Start ist jede Mitteilung beiden Brands zugewiesen. Komponenten brauchen dafür keine Sonderlogik – sie filtern nach Brand-Kontext, und der Pool ist eben (am Anfang) für beide Brands derselbe.
## 9. Entwicklungs-Reihenfolge (Empfehlung)
Konkrete Bauplan-Sequenz, die früh nutzbare Ergebnisse liefert:
**Sprint 1 – Fundament**
- Brand-Model, Middleware, Resolver
- Theming-Setup (Tailwind v4, CSS-Variablen, zwei Brand-Themes)
- Layout `brand.blade.php`
- Grundlegende UI-Komponenten (`button`, `badge`, `section-header`)
**Sprint 2 – Statisches Markup für businessportal24**
- TopBar, Header, RubrikenNav, Footer
- `` und seine Varianten
- StatsRow, QualityStandardFooter
- Statische Version der Veröffentlichen-Landing (ohne Reaktivität)
**Sprint 3 – Reaktive Komponenten**
- AdHocTicker (Volt + Polling)
- HeroSlider (Volt + Alpine)
- PressList mit Filter-Tabs
- Hub-Transition-Block mit Cross-Domain-Auth-Übergabe
**Sprint 4 – Hub-Anbindung**
- Sanctum-Setup für Cross-Domain
- Hub-Routing für `?brand=businessportal24`-Parameter
- Einreichungs-Flow im Hub (klassisches Livewire)
**Sprint 5 – Zweite Brand aufschalten**
- `presseecho.test` lokal
- Brand-Config für presseecho
- Erste Override-Komponente: `topic-cluster`-Hero
- Testen: was funktioniert ohne Override, was braucht eines?
Ab Sprint 5 wird die eigentliche Stresstest-Frage beantwortet: **Hält die Architektur, wenn die zweite Brand wirklich anders aussehen soll?** Wenn an Sprint 5 viele Overrides nötig werden, ist die Config-Schicht zu dünn – dann iterieren.
## 10. technische Punkte
- **Tailwind v4:** wenn das Projekt noch nicht migriert ist, sollte das _vor_ Sprint 1 entschieden werden. v4 macht das CSS-Variablen-Setup deutlich eleganter.
- **Sanctum-Cookie-Domain für Cross-Domain-Auth:** Detail aus Update 3, muss vor Sprint 4 final geklärt sein. Same-Site-Strategie, SPA-Mode oder klassischer Token-Flow?
- **CDN/Asset-Hosting:** Brand-Bilder, Press-Item-Fotos – kommen vom Hub
- **Translations:** DACH-Sprachschalter auf der Startseite –(de (ohne parameter) / de-at / de-ch / en) ist eine reine Inhalts-Filterung. Bei Mehrsprachigkeit de/en: i18n-Setup
- **Polling-Frequenzen:** AdHocTicker, Newsroom-Liste – wie oft refreshen, ohne dass die Server-Last bei wachsendem Traffic problematisch wird? Anfangswerte: Ticker 30s, Newsroom 60s, Branchen-Index 5 min.
---
_Dieses Konzept ist die technische Brücke zwischen Architektur (Update 3), Positionierung (Update 4) und Implementation. Es legt fest, wie Komponenten strukturiert werden, damit die Brand-Differenzierung skaliert – ohne in eine Codebase-Duplikation zu kippen. Anpassungen sollten dokumentiert und mit den Update-Dokumenten abgeglichen werden._