Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.
Release Candidates sind nicht für Production gedacht. Sie gehören in die CI, auf Staging und auf eure lokalen Maschinen.
# .github/workflows/tests.yml
jobs:
phpunit:
runs-on: ubuntu-latest
strategy:
matrix:
php: ['8.4', '8.6']
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: ${{ matrix.php }}
ini-values: error_reporting=E_ALL
- run: composer install --no-progress
- run: vendor/bin/phpunit
# Welche Pakete blockieren PHP 8.6?
composer prohibits php 8.6
# Danach Pakete aktualisieren und Sicherheit prüfen
composer update --with-all-dependencies
composer audit
// rector.php
use Rector\Config\RectorConfig;
return RectorConfig::configure()
->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
->withPhpSets();
vendor/bin/rector process --dry-run
grep -rnE "function (is|let|readonly)\s*\(" src tests
grep -rn "spl_object_hash" src vendor --include=*.php | head
composer check-platform-reqs
php -v
php-fpm -v
I think we should think very carefully whether we can avoid disrupting that much code.
PHP 8.0 bis 8.6 im Vergleich: Named Arguments, Enums, Property Hooks, Pipe Operator, Partial Function Application. Features, Support und Upgrade mit Rector.
Mehr erfahren
Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.
PHP 8.6.0 ist laut offiziellem Zeitplan im PHP Wiki für den 19. November 2026 geplant. Der letzte Release Candidate RC5 erschien am 5. November. Neue Features kommen nicht mehr dazu, Release Candidates enthalten nur noch Bugfixes. Die Zeit bis zum Release eignet sich ideal, um eure Anwendung in der CI gegen PHP 8.6 zu testen.
Ja, aber nur in der CI, auf Staging und lokal. Ein zusätzlicher Pipeline Job mit PHP 8.6 kostet wenig und zeigt Deprecations und Brüche früh. Fehler, die ihr jetzt findet, könnt ihr noch an das PHP Team melden. Production stellt ihr erst nach dem finalen Release um.
Am häufigsten treffen die neuen Session Defaults mit Strict Mode, HttpOnly und SameSite Lax. Sie können Login Flows und Payment Rücksprünge stören. Dazu kommen Funktionen, die jetzt bei ungültigen Werten einen ValueError werfen, und reservierte Namen wie is und let, die eine Deprecation auslösen.
Für eine Umstellung in den nächsten Wochen ist PHP 8.5 die sichere Wahl, mit Security Fixes bis Ende 2029. PHP 8.4 passt, wenn euer Ökosystem noch nicht weiter ist. PHP 8.6 lohnt sich für neue Projekte und für Teams, die ihren Rollout nach dem Release planen.
Das hängt vor allem von Testabdeckung und Abhängigkeiten ab, nicht von der Größe des Codes. Mit gutem Test Setup und Rector ist ein Upgrade von 8.5 auf 8.6 oft schnell erledigt. Fehlen Tests oder blockieren alte Pakete, kostet die Vorarbeit die meiste Zeit. Eine ehrliche Schätzung geht erst nach einem Blick in den Code.
Deprecations sind Funktionen und Schreibweisen, die noch funktionieren, aber eine E_DEPRECATED Meldung auslösen. Sie werden mit PHP 9 entfernt. Für PHP 8.6 wurden in einer Sammel RFC 31 Vorschläge angenommen, darunter Alias Funktionen wie is_integer(), spl_object_hash() und reservierte Namen wie let und is.
Mit dem Befehl composer prohibits php 8.6. Composer listet jedes installierte Paket, dessen Versionsangabe PHP 8.6 ausschließt, und nennt die passende Regel. Aktualisiert diese Pakete zuerst, solange ihr noch auf eurer alten PHP Version seid. So bleibt der eigentliche Wechsel klein und überschaubar.
Rector schreibt Code automatisch auf neue Syntax um und löst viele Deprecations. Mit einem leeren withPhpSets() liest es die Zielversion aus der composer.json. Rector ändert nur, was es sicher umschreiben kann. Verhaltensänderungen in aufgerufenen Funktionen findet es nicht, dafür braucht ihr Tests und statische Analyse.
Weil RC3 drei Regressionen korrigiert hat, die PHP 8.6 selbst eingeführt hatte. Fibers starteten ohne php.ini mit abgeschalteten Warnungen, hrtime() lief auf manchen Systemen zu schnell und array_map() warf im Strict Mode TypeErrors. Wer auf früheren Builds getestet hat, hat womöglich falsche Ergebnisse gesehen.
Für kritische Nutzerwege ja. Unit Tests prüfen einzelne Klassen, aber die neuen Session Defaults wirken erst im Browser. Login, Checkout, Formulare und Payment Rücksprünge sichert ihr am besten mit Cypress ab. So seht ihr nach jedem Upgrade Schritt, ob die wichtigsten Wege noch funktionieren.
Ja, für Release Candidates gibt es Builds, die ihr in der CI oder lokal starten könnt. Achtet darauf, dass offizielle Images ohne php.ini laufen. Genau dort trat in den Betas der Fiber Fehler auf. Setzt error_reporting deshalb bewusst auf E_ALL, damit ihr alle Meldungen seht.
Zunächst nichts. Euer Code läuft unter PHP 8.6 weiter und schreibt nur Meldungen ins Log. Mit PHP 9 werden die betroffenen Funktionen aber entfernt, dann bricht der Code. Je länger ihr wartet, desto mehr Stellen sammeln sich. Kleine Fixes direkt beim Upgrade sind deutlich günstiger.
