e3dc1afd8e
Enth\u00e4lt gemischt: Laravel-10-Upgrade + Phase 1 (Contacts-Modul, Duplicats-Commands, Soft-Delete+Merge-Fields) + Phase 2 Code-Umstellungen (inquiry_id, $table='contacts'/'inquiries') + Offers-Modul (Migrationen, Models, offer_id in Booking, offer-Disk in filesystems.php). Phase 2 + Offers werden im folgenden Commit nach dev/backups/phase2-offers-2026-04-17/ verschoben, damit der Workspace auf Phase-1-only (= Test-System-Stand) reduziert ist und direkt auf Live deploybar wird. Tarball-Backup zus\u00e4tzlich unter: ../backups-safety/workspace-pre-phase1-rollback-2026-04-17.tar.gz Made-with: Cursor
138 lines
8.3 KiB
Markdown
138 lines
8.3 KiB
Markdown
# Projekt-Analyse: sinnvolle Erweiterungen und Optimierungen (mein.sterntours.de)
|
||
|
||
Stand: April 2026. Dieses Dokument ergänzt und aktualisiert die frühere Übersicht in [`audit-april-2025.md`](./audit-april-2025.md) und fasst zusätzliche Beobachtungen aus Code-Struktur, Abhängigkeiten und typischen Laravel-Betriebsmustern zusammen.
|
||
|
||
---
|
||
|
||
## Kurzfassung
|
||
|
||
Das CRM ist ein ausgereiftes **Laravel-10**-Monolith mit klarer Schichtung (Controller → Request/Repository → Services/Models), **Zwei-Datenbank-Setup** (CRM + read-only Legacy) und **Passport** für API-Bereiche. Die größten Hebel für die nächsten Monate sind: **Wartbarkeit** (Duplikate reduzieren, moderne Laravel-Konventionen), **Sicherheit** (öffentliche API-Endpunkte härten), **Qualität** (Tests, statische Analyse), **Frontend-Tooling** (langfristig von Laravel Mix 2 weg) und **Betrieb** (Scheduler, Monitoring, asynchrone Mail).
|
||
|
||
---
|
||
|
||
## Abgleich mit dem Audit April 2025
|
||
|
||
| Thema | Früher (Audit) | Aktueller Stand (Code-Review) |
|
||
|--------|------------------|-------------------------------|
|
||
| API-Key Booking-Import | Hardcoded im Controller | **Erledigt im Sinne von Konfiguration:** `API/BookingController` nutzt `config('app.success_key')` → `env('SUCCESS_KEY')` in `config/app.php`. Sicherstellen, dass `.env`/`SUCCESS_KEY` in allen Umgebungen gesetzt und **nicht** ins Repo gelangt. |
|
||
| PHPUnit / SQLite zweite DB | `mysql_stern` fehlt in Tests | **Weiterhin relevant:** In `phpunit.xml` sind keine `DB_*`-Variablen für die Stern-Verbindung gesetzt; Tests mit Legacy-Models bleiben erschwert. |
|
||
| Frontend (Mix 2, node-sass) | Veraltet | **Unverändert:** `package.json` mit Laravel Mix **2.1** und sehr altem Ökosystem – größeres Migrationsprojekt. |
|
||
| Code-Duplizierung Booking/Lead (Mail-Verzeichnisse) | Offen | **Weiterhin sinnvoll:** Gemeinsamen Service/Trait extrahieren. |
|
||
|
||
---
|
||
|
||
## 1. Architektur und Wartbarkeit
|
||
|
||
### 1.1 Gemeinsame Logik zusammenführen
|
||
|
||
- **Mail-Verzeichnis-Logik** in `Services/Booking.php` und `Services/Lead.php` (siehe Audit): Ziel sollte ein klar benannter **`MailDirService`** (oder Trait nur, wenn wirklich nur technische Wiederholung) sein, inklusive Tests.
|
||
- **Parallele Mail-Repositories** (`CustomerMailRepository`, `LeadMailRepository`, `CustomerFewoMailRepository`): `sendMail`/`prepareMessageFull` sind sich sehr ähnlich – mittelfristig Basis-Klasse oder gemeinsames **„Mail senden mit Anhängen/Fehlerstatus“**-Modul prüfen (ohne Big-Bang-Refactoring).
|
||
|
||
### 1.2 Laravel-Konventionen und Typisierung
|
||
|
||
- Controller-Methoden mit **`Illuminate\Http\Request` injizieren** statt `\Request::all()` (globale Facade), wo möglich – verbessert Testbarkeit und IDE-Unterstützung.
|
||
- **`BaseRepository` und ältere Services** schrittweise mit **Return-Types** und strengeren Parametertypen versehen (Audit erwähnt das bereits).
|
||
- API-Routen nutzen noch **String-Controller-Referenzen** (`'API\BookingController@import'`). Migration auf **Klassen-Syntax** (`[BookingController::class, 'import']`) erleichtert spätere Laravel-11/12-Upgrades und Refactoring-Tools.
|
||
|
||
### 1.3 Offene TODOs gezielt abarbeiten
|
||
|
||
Im Projekt existieren zahlreiche `//TODO`-Marker (u. a. CMS, Settings „linked“-Prüfungen, Mail-Modals „load subdirs by pos id“, IQ-ContentTree). Sinnvoll ist ein **kleines Backlog** nach Kategorie (Bug, UX-Schuld, Sicherheit) – nicht alles auf einmal, aber sichtbar machen, damit keine stillen Lücken bleiben.
|
||
|
||
---
|
||
|
||
## 2. Sicherheit
|
||
|
||
### 2.1 Öffentliche API-Endpunkte
|
||
|
||
- **`POST /api/navigation/cache/clear`** ist ohne `auth:api` definiert. Jeder kann damit theoretisch den Navigations-Cache leeren (DoS/Cache-Störung). **Empfehlung:** Secret-Header, IP-Allowlist, oder **nur authentifizierte** Aufrufer (je nach Aufrufer-Architektur).
|
||
- **`booking/import`** akzeptiert laut Routen **GET und POST**. GET-Requests mit Seiteneffekten (Import) sind problematisch (Logs, Proxies, prefetch). **Empfehlung:** nur **POST**, dokumentieren; Legacy-GET nur temporär mit Deprecation-Header/Log.
|
||
- Booking-Import: Neben dem Shared Secret **Rate-Limiting** prüfen (eigener `RateLimiter::for('booking-import', …)`), falls der Endpunkt von wenigen festen IPs kommt: zusätzlich **IP-Bindung** in Middleware.
|
||
|
||
### 2.2 API allgemein
|
||
|
||
- Öffentliche Routen (`cms/*`, `passolution`, `navigation/*`) sollten einmal **inventarisiert** werden: Welche liefern personenbezogene oder interne Daten? Braucht es **API-Versionierung** (`/api/v1/...`) für externe Konsumenten?
|
||
|
||
### 2.3 Abhängigkeiten
|
||
|
||
- In `composer.json` stehen mehrere Pakete mit **`"*"`** (z. B. `iqcontent/laravel-filemanager`, `jenssegers/date`, …). **Empfehlung:** auf **konkrete Versionen** pinnen, um reproduzierbare Builds und Sicherheits-Updates zu gewährleisten.
|
||
|
||
---
|
||
|
||
## 3. Performance und Skalierung
|
||
|
||
### 3.1 E-Mail synchron im Request
|
||
|
||
Versand erfolgt in Repositories per `Mail::…->send()` im gleichen Prozess wie der HTTP-Request. Unter Last verlängert das Antwortzeiten.
|
||
|
||
- **Kurz:** `Mail::queue()` bzw. **Queued Mailables** / **`ShouldQueue`** für nicht-kritische Benachrichtigungen.
|
||
- **Voraussetzung:** zuverlässiger **Queue-Worker** (Supervisor/Docker) und Monitoring fehlgeschlagener Jobs.
|
||
|
||
### 3.2 Scheduler
|
||
|
||
`app/Console/Kernel.php` enthält einen **leeren** `schedule()`-Block. Wenn Cron-Jobs extern oder in anderer Form laufen, **dokumentieren**; sonst wiederkehrende Tasks (Newsletter-Sync, Bereinigungen, Cache-Warmup) **hier** oder als dokumentierte `artisan`-Crons abbilden – sonst droht „vergessene“ Automatisierung bei Serverwechsel.
|
||
|
||
### 3.3 Caching
|
||
|
||
- Navigation nutzt bereits Caching im Service – gut. **Strategie:** TTLs, Cache-Tags (falls Redis/Memcached), und Invalidierung nur über vertrauenswürdige Wege (siehe 2.1).
|
||
|
||
---
|
||
|
||
## 4. Qualität, Tests und Entwicklererfahrung
|
||
|
||
### 4.1 Testabdeckung
|
||
|
||
Aktuell ein **kleines Set** Feature/Unit-Tests (siehe Audit-Liste). Sinnvolle nächste Schritte:
|
||
|
||
- **Factories** für zentrale Domänenobjekte (`Customer`, `Booking`, `Lead`) – Audit nennt das bereits.
|
||
- **Zweite DB in PHPUnit** konfigurieren (Audit-Vorschlag mit SQLite zweiter Connection), damit Legacy-Models überhaupt testbar werden.
|
||
- Kritische **API-Verträge** (Booking-Import, Fewo-API) mit **Contract-Tests** absichern.
|
||
|
||
### 4.2 Statische Analyse und Formatierung
|
||
|
||
- **Laravel Pint** (oder PHP-CS-Fixer) für einheitlichen Style – aktuell keine `pint.json` im Projektroot sichtbar.
|
||
- **PHPStan/Larastan** (Level schrittweise erhöhen) für frühe Fehler in Repositories und Services.
|
||
|
||
### 4.3 Observability
|
||
|
||
- Zentral **strukturiertes Logging** für API-Fehler (ohne Secrets), optional eigener Log-Channel für `booking/import`.
|
||
- Langfristig: **Laravel Pulse** oder APM (wenn nicht schon vorhanden) für langsame Requests und Queue-Latenzen.
|
||
|
||
---
|
||
|
||
## 5. Frontend und Assets
|
||
|
||
Unverändert zur Einschätzung im Audit:
|
||
|
||
- **Laravel Mix 2**, **Bootstrap 4**, **node-sass** – technisch am Ende der Fahnenstange.
|
||
- **Sinnvolle Richtung:** Migration auf **Vite** + **sass (dart-sass)** + schrittweise **Bootstrap 5** oder gezieltes Design-System – als **eigenes Projekt** mit Pilot-View und Build-Pipeline in CI.
|
||
|
||
---
|
||
|
||
## 6. Framework- und PHP-Roadmap
|
||
|
||
- **Laravel 10** ist LTS-fähig; mittelfristig **Upgrade-Pfad zu Laravel 11** planen (Routing, `bootstrap/app.php`, strukturelle Änderungen).
|
||
- **`jenssegers/date`** ist überflüssig, wenn überall **Carbon** genutzt wird – Dependency reduzieren.
|
||
- **PHP:** `composer.json` erlaubt 8.1–8.3; einheitliche **8.2/8.3**-Zielversion in CI und Docker festlegen.
|
||
|
||
---
|
||
|
||
## 7. Priorisierte Maßnahmen (Vorschlag)
|
||
|
||
| Priorität | Maßnahme | Aufwand |
|
||
|-----------|----------|---------|
|
||
| Hoch | `navigation/cache/clear` absichern (Auth/Secret/IP) | Klein–mittel |
|
||
| Hoch | `booking/import`: nur POST, Rate-Limit; Aufrufer-Doku | Klein |
|
||
| Hoch | Composer-`**`-Versionen durch feste Versionen ersetzen | Mittel |
|
||
| Mittel | `MailDirService` / Duplikate Booking–Lead | Mittel |
|
||
| Mittel | Mail-Versand für geeignete Fälle über Queue | Mittel–groß |
|
||
| Mittel | PHPUnit: zweite DB + mehr Factories | Mittel |
|
||
| Mittel | Pint + Larastan einführen (CI) | Mittel |
|
||
| Niedrig | API auf Klassen-Routen, Request-Injection ausbreiten | Laufend |
|
||
| Strategisch | Frontend: Vite + Tooling-Modernisierung | Groß |
|
||
|
||
---
|
||
|
||
## Referenz
|
||
|
||
- Bestehende Detail-Audits und Test-Kommandos: [`audit-april-2025.md`](./audit-april-2025.md)
|
||
- UI-/Navigations-Kontext: [`frontend-navigation/BACKEND-UI.md`](./frontend-navigation/BACKEND-UI.md)
|