mein-sterntours/dev/projekt-empfehlungen-2026-04.md

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 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
• UI-/Navigations-Kontext: frontend-navigation/BACKEND-UI.md