# PHP 8.2 mit Laravel 5.8

> Historischer Stand des Branches `feature/php_8.2`. Fuer Laravel 12 gilt
> stattdessen [LARAVEL12.md](LARAVEL12.md); die alten Vendor-Patches entfallen.

Dieser Branch uebernimmt die in ASP getesteten Kompatibilitaetskorrekturen.
Laravel bleibt auf **5.8.30**. Dies ist kein Upgrade auf Laravel 12 und keine
offiziell unterstuetzte oder sicherheitsbereinigte Framework-Version.

Der Commit enthaelt auch den zuvor uncommitteten Anwendungsstand (unter anderem
Kuenstlerfelder, Importverarbeitung und jQuery 3.6), damit diese Voraussetzungen
bei der Auslieferung erhalten bleiben. Die Importklassen wurden an die vorhandene
Excel-Version angepasst; leere Zeilen werden ohne Datenbankschreibzugriff
verworfen. IDE-Dateien und lokale Datendateien bleiben ausserhalb des Commits.

## Code und Abhaengigkeiten

- Deprecations werden protokolliert, statt Requests abzubrechen. Andere
  Warnungen und Fehler bleiben sichtbar im Fehlerhandling; PHP-Diagnosen
  werden nicht in HTTP-Antworten ausgegeben.
- Carbon, DBAL und erforderliche Abhaengigkeiten entsprechen dem getesteten
  Docker-Stand. Das Repository versioniert bereits `vendor`; die geaenderten
  Dateien und `composer.lock` werden deshalb gemeinsam ausgeliefert.
- Zwei Laravel-Dispatchstellen verwenden positionelle Parameter unter PHP 8.
  Die Paketerkennung versteht auch das Composer-2-Format.
  `scripts/apply-php82-compat.php` stellt diese Anpassungen nach Composer wieder
  her, ist mehrfach ausfuehrbar und bricht bei unerwartetem Quelltext ab.
- Dashboard-Laufzeit meldet fehlende oder ungueltige Serviceantworten mit
  begrenzter Wartezeit. Crawler, Fehlerliste und Historie erhalten die
  Datenbankabfrage- und Sortierkorrekturen; leere Filterergebnisse werden
  verstaendlich angezeigt.
- Vorselektion zeigt bei fehlenden Stagingtabellen einen Hinweis; der
  Ajax-Endpunkt liefert dann explizit HTTP 503. Der separate Stagingdump wird
  weiterhin benoetigt. Die Bulk-Update-Syntax ist fuer PHP 8 korrigiert.

## Auslieferung

1. Anwendung vor der Auslieferung sichern und zuerst in einer Testumgebung
   pruefen. Die alten Pakete haben weiterhin bekannte Sicherheitsprobleme.
2. Eigene `.env` mit APP_KEY, Datenbankverbindungen und Serviceadressen
   bereitstellen. Zugangsdaten und Docker-Laufzeitdateien sind kein Bestandteil
   dieses Commits. `localhost` in Docker bezeichnet den jeweiligen Container.
3. Die versionierten Abhaengigkeiten mit ausliefern. Falls sie aus dem Lockfile
   neu installiert werden muessen, ist unter PHP 8.2 wegen der alten
   PHP-Versionsgrenzen voruebergehend folgender Befehl erforderlich:

   ```sh
   composer install --no-dev --prefer-dist --ignore-platform-req=php
   ```

   Keine pauschale Deaktivierung der Erweiterungspruefungen und kein
   unkontrolliertes `composer update` verwenden. Der Composer-Hook wendet die
   Dispatchkorrekturen vor `artisan package:discover` an. Bei `--no-scripts`
   muss `php scripts/apply-php82-compat.php` manuell ausgefuehrt werden.
4. Schreibrechte fuer `storage` und `bootstrap/cache` setzen, alte Config- und
   View-Caches leeren und PHP-FPM/Apache bzw. OPcache nach dem Austausch der
   Dateien neu laden. Login, Listen, Filter und Servicezugriff pruefen.

Datenbankindizes und Serverkonfiguration sind separate Betriebsschritte;
ein Git-Commit legt keine Indizes an und aendert keinen Datenbank-Cache.
Die vorhandenen Auslieferungsscripte liegen unter `deployment/performance`.
Die Historie zaehlt im Branch exakt: die lokale Docker-Abkuerzung `MAX(id)`
waere bei geloeschten Datensaetzen oder anderen Dumps unzuverlaessig.

## Pruefumfang

Im isolierten Commit-Stand unter PHP 8.2 geprueft: Artisan 5.8.30,
Composer-Paketerkennung ohne vorhandenes Manifest, erneutes Anwenden der
Vendor-Patches, Dashboard-Antworten, Kuenstler-Paginierung, Crawler-Sortierung
und exakte Zaehler gegen Referenz-SQL, Historie, Fehlerliste, Staging-Ausfall,
Blade-/PHP-Syntax und normales Fehlerhandling.

Importklassen wurden auf Ladefaehigkeit und isolierte Zeilenkonvertierung
geprueft, ohne Daten zu speichern. Vollstaendige Importablaeufe sind nicht
abgenommen: `AuctionObjectStageImport` besitzt bereits im bisherigen Code keine
freigegebenen Mass-Assignment-Felder. Direktes Erzeugen mit Zeilendaten wird
deshalb ohne gesonderte Freigabe abgewehrt. Das wurde nicht pauschal entsperrt.
Fuer echte Vorselektionsablaeufe fehlt ausserdem weiterhin der Stagingdump.