PHP 8.6 Alpha 2: Diese drei Änderungen sollten Sie jetzt testen

Am 16. Juli erschien PHP 8.6.0 Alpha 2. Wer meine bisherigen Artikel zu 8.6 verfolgt hat, kennt clamp(), SortDirection und die Polling API bereits. Was in Alpha 2 neu dazugekommen ist, fällt in eine andere Kategorie: Drei Änderungen, die nicht als Feature verkauft werden, aber bestehenden Code stiller brechen können als jedes neue Sprachkonstrukt. Bis zum Feature Freeze am 13. August bleibt Zeit, das im eigenen Projekt zu prüfen.

Der 14-tägige Alpha-Zyklus läuft planmäßig weiter: Alpha 3 am 30. Juli, Feature Freeze mit Beta 1 am 13. August, GA-Ziel am 19. November. Wie ich im Alpha-1-Realitätscheck beschrieben habe, ist das Tempo, mit dem einzelne Features landen, ein gutes Signal für die Qualität der Roadmap. Alpha 2 bestätigt das mit denselben bekannten Nice-to-haves wie grapheme_strrev(), Uri\Rfc3986\UriBuilder und dem SortDirection-Enum, die bereits in Alpha 1 sichtbar waren.

PHP 8.6 Alpha 2: Priorität nach Impact

Warum die Session-Defaults der größte praktische Einschnitt sind

Die "Secure Session Configuration Defaults" RFC von Jorg Sowa wurde ohne eine einzige Gegenstimme angenommen, obwohl ein ähnlicher Vorschlag 2016 abgelehnt worden war. Sie kippt drei INI-Defaults, die seit Jahren hinter den OWASP-Empfehlungen zurücklagen.

# PHP 8.6: Geänderte Session-Defaults
session.use_strict_mode:   0 → 1   # blockiert Session-Fixation
session.cookie_httponly:   0 → 1   # JS kann Session-Cookie nicht mehr lesen
session.cookie_samesite:   "" → "Lax"  # Cookie nicht mehr bei Cross-Site-POST

# Wichtig: Diese Defaults gelten nur für NEUE Setups.
# Bereits explizit gesetzte php.ini-Werte bleiben unverändert.

use_strict_mode verhindert Session-Fixation, indem PHP eine vom Client vorgeschlagene, aber unbekannte Session-ID nicht mehr akzeptiert, sondern eine neue generiert. cookie_httponly schließt den häufigsten XSS-Payload aus, das Auslesen der Session-ID über document.cookie. cookie_samesite=Lax unterbindet den Versand des Session-Cookies bei Cross-Site-POST-Requests, was den gängigsten CSRF-Vektor kappt.

Genau hier liegt der praktische Haken. Wer SameSite=Lax als neuen Default bekommt, verliert automatisch die Cookie-Übertragung bei SP-initiierten SAML-SSO-Flows oder älteren Cross-Origin-Formular-Einreichungen, die auf das automatische Mitsenden des Session-Cookies angewiesen waren. Für diese Endpunkte muss SameSite=None; Secure jetzt explizit gesetzt werden, oder der Flow wird auf ein Token-basiertes Verfahren umgestellt.

Was sich beim Error-Handling ändert

Warum werden Warnings jetzt zu Exceptions?

PHP 8.6 vereinheitlicht das Error-Handling in Kernfunktionen: Statt einer stillen Warning bei ungültigen Argumenten werfen mehr Funktionen jetzt konsistent ValueError oder TypeError. array_filter()'s $mode-Parameter etwa wirft bei einem ungültigen Wert jetzt einen ValueError, statt den Aufruf mit einer Warning stillschweigend zu ignorieren.

// PHP vor 8.6: stille Warning, Ausführung läuft weiter
// mit möglicherweise falschem Ergebnis

// PHP 8.6: klarer Fehler, der Aufruf-Stack stoppt an der Stelle
try {
    array_filter($data, $callback, mode: 999); // ungültiger Mode
} catch (\ValueError $e) {
    // Fehler ist jetzt explizit behandelbar
}

// clamp() folgt demselben Prinzip:
clamp($value, min: NAN, max: 10);
// wirft ValueError, weil NAN als Grenze ungültig ist

Was viele unterschätzen: Code, der @-Fehlerunterdrückung oder einen pauschalen set_error_handler() nutzt, um Warnings global abzufangen, sieht diese Fehler jetzt nicht mehr an derselben Stelle. Exceptions propagieren anders als Warnings, sie durchbrechen den Call-Stack, statt nur geloggt zu werden. Wer sich auf das alte Warning-Verhalten verlassen hat, etwa um fehlerhafte Eingaben stillschweigend zu ignorieren, muss das jetzt explizit mit try/catch abfangen.

Was der Mbregex-Deprecation-Pfad bedeutet

Die Mbregex-Extension (mb_ereg(), mb_eregi() und verwandte Funktionen) ist mit 8.6 als deprecated markiert. Die Funktionen funktionieren weiterhin, geben aber Deprecation-Notices aus. Die empfohlene Migration führt zu preg_*()-Funktionen mit dem u-Modifier für UTF-8-Verarbeitung.

// Alt: Mbregex (deprecated ab PHP 8.6)
$result = mb_ereg('^[a-zäöü]+$', $input);

// Neu: preg_* mit u-Modifier für UTF-8
$result = preg_match('/^[a-zäöü]+$/u', $input);

// Für komplexere Multibyte-Patterns ggf. \p{L}
// für Unicode-Buchstabenklassen nutzen:
$result = preg_match('/^\p{L}+$/u', $input);

Der Migrationsaufwand hängt stark davon ab, wie tief Mbregex-Funktionen im Projekt verankert sind. Für einzelne Validierungsroutinen ist der Umstieg auf preg_*() meist eine Sache von Minuten pro Stelle. Projekte mit umfangreicher Textverarbeitung, die auf Mbregex-spezifische Encoding-Behandlung angewiesen sind, sollten die Migration als eigenen Aufgabenblock einplanen, nicht als Nebenbei-Fix kurz vor GA.

Wie testen Sie das konkret vor dem Feature Freeze?

Wie ich im ersten Alpha-Artikel beschrieben habe, bleibt die Strategie unverändert: Ein separater CI-Job gegen die Alpha, der den Haupt-Build nicht blockiert. Für die drei Prioritäten aus Alpha 2 lohnt sich ein gezielter, zusätzlicher Test-Schritt.

# Session-Verhalten gezielt testen:
# php.ini der Test-Umgebung ohne explizite Session-Overrides laufen lassen
# und SSO-/Formular-Flows gegen die neuen Defaults prüfen

# Deprecation-Notices sichtbar machen für Mbregex-Aufrufe:
error_reporting(E_ALL);
ini_set('display_errors', '1');

# grep nach Mbregex-Funktionen im Projekt:
$ grep -rn "mb_ereg" src/

Zusammenfassung

PHP 8.6 Alpha 2 erschien am 16. Juli. Alpha 3 folgt am 30. Juli, Feature Freeze mit Beta 1 am 13. August, GA am 19. November.

Session-Security-Defaults: use_strict_mode, cookie_httponly und cookie_samesite=Lax werden zum Standard für neue Setups. SP-initiierte SSO-Flows und Cross-Origin-Formulare sind die kritischen Testfälle.

Error-Handling: ValueError/TypeError ersetzen stille Warnings in mehr Kernfunktionen. Code mit globaler Fehlerunterdrückung sollte gezielt geprüft werden.

Mbregex-Deprecation: Migration zu preg_*() mit u-Modifier oder \p{L}-Klassen, Zeit bis GA vorhanden.