PHPCompatibility prüft PHP Code gegen eine Ziel Version. Installation, testVersion, Grenzen des Tools und der richtige Platz im Upgrade auf PHP 8.
Mehr erfahren
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.
composer prohibits php 8.5
composer audit
vendor/bin/rector process --dry-run
The target you pick decides how soon you'll be doing this again.
PHPCompatibility prüft PHP Code gegen eine Ziel Version. Installation, testVersion, Grenzen des Tools und der richtige Platz im Upgrade auf PHP 8.
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.2 erreicht am 31. Dezember 2026 sein End of Life. Ab diesem Tag veröffentlicht das PHP Team keine Releases mehr für den 8.2 Zweig, auch keine Sicherheitsupdates. Aktiven Support mit Bugfixes gibt es schon seit Ende 2024 nicht mehr. Die letzte Version ist aktuell PHP 8.2.35 vom 21. Oktober 2026.
Ja, eure Website läuft technisch weiter. PHP schaltet sich nicht ab. Neu entdeckte Sicherheitslücken werden aber nicht mehr geschlossen, und neue Versionen von Frameworks und Paketen lassen sich nach und nach nicht mehr installieren. Das Risiko steigt still im Hintergrund, bis ein Angriff oder ein Hoster Wechsel es sichtbar macht.
Für die meisten Teams ist PHP 8.5 jetzt das beste Ziel, mit aktivem Support bis Ende 2027 und Sicherheitsfixes bis Ende 2029. PHP 8.3 ist der kleinste Sprung, endet aber schon Ende 2027. PHP 8.6 erscheint am 19. November 2026 und passt, wenn euer Rollout erst danach ansteht.
Das hängt vor allem von Tests und Abhängigkeiten ab. Mit gutem Test Setup und Rector ist ein Sprung von 8.2 auf 8.5 oft in überschaubarer Zeit machbar. Fehlen Tests oder blockieren alte Pakete, braucht die Vorarbeit am meisten Zeit. Eine ehrliche Schätzung ist erst nach einem Blick in den Code möglich.
PHP2Shell waren zwei kritische Lücken mit CVSS 9.2, die im Oktober 2026 geschlossen wurden. PHP 8.2 bekam den Fix noch mit Version 8.2.35. Nach dem 31. Dezember 2026 gäbe es für eine vergleichbare Lücke kein offizielles Release mehr. Genau deshalb solltet ihr das Upgrade jetzt planen.
Ja, das ist normal. Ein Sprung von PHP 8.2 direkt auf 8.5 ist üblich. Ihr lest die Migrationsguides jeder übersprungenen Version, also für 8.3, 8.4 und 8.5, und lasst Rector sowie eure Tests gegen die Zielversion laufen. Der Aufwand steckt in den Änderungen, nicht in der Zahl der Versionen.
Ja. Rector schreibt veraltete Syntax und viele Deprecations automatisch um. Mit einem leeren withPhpSets() liest es die Zielversion aus der composer.json. Rector ändert aber nur, was es sicher umschreiben kann. Verhaltensänderungen in aufgerufenen Funktionen findet es nicht, dafür braucht ihr Tests und statische Analyse.
Mit php -v auf der Kommandozeile. Prüft aber auch PHP FPM, denn CLI und Webserver können unterschiedliche Builds nutzen. Dazu gehören Cronjobs, Queue Worker, Docker Base Images und die Images eurer CI. Erst wenn ihr alle Stellen kennt, wisst ihr, was umgestellt werden muss.
Teilweise ja. Red Hat führt die php 8.2 Streams für RHEL 8 und RHEL 9 bis Mai 2029. Das deckt aber nur die PHP Pakete der Distribution ab. Eure Composer Abhängigkeiten und Frameworks ziehen trotzdem weiter. Vendor Support kauft also Zeit für das Upgrade, ersetzt es aber nicht.
Sie laufen weiter, verlieren aber ab Januar 2027 den Schutz durch Sicherheitsupdates für PHP selbst. Prüft vor dem Wechsel, ob Theme und Plugins die Zielversion unterstützen. Die meisten Probleme kommen aus alten Plugins, nicht aus WordPress selbst. Ein Test auf Staging mit der neuen PHP Version zeigt Fehler, bevor Besucher sie sehen.
Ja. Die PHP Version steckt oft im Base Image, etwa in der FROM Zeile eures Dockerfiles. Stellt dort die Zielversion ein und prüft, ob alle benötigten Extensions mitkommen. Vergesst die Images in eurer CI nicht. Sonst testet die Pipeline gegen eine andere Version als Production.
Es gibt keine Pauschale, weil jedes Projekt anders ist. NCA startet mit einem kostenlosen Kennenlernen, schätzt danach den Aufwand anhand eures Codes und rechnet transparent minutengenau ab. Durch Rector, statische Analyse und automatisierte Tests sinkt der Aufwand deutlich gegenüber einer rein manuellen Migration.