NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Brücke, Sanduhr mit PHP 8.2 End of Life und Team mit Umzugskarton

Was PHP 8.2 End of Life bedeutet

PHP 8.2 End of Life ist das Ende jeder Unterstützung für PHP 8.2 zum Jahresende 2026. Danach veröffentlicht das PHP Team keine Releases mehr für den 8.2 Zweig, auch keine Sicherheitsupdates. Eure Anwendung läuft weiter, aber jede neu entdeckte Lücke bleibt offen.
PHP 8.2 bekommt schon seit Ende 2024 nur noch Sicherheitsfixes. Die letzte Version ist PHP 8.2.35. Wer heute noch auf 8.2 oder älter läuft, sollte das Upgrade jetzt planen. Wie sich alle PHP 8 Versionen unterscheiden, zeigt unser PHP 8 Versionen Vergleich.
Inhalt
NCA Cypress Workshop mit Cypress Ambassador Roland Golla

E2E Tests, die euer Team selbst schreibt

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.

  1. 1
    Kostenloses Vorgespräch
    Projekt, Stack und Teststand klären
  2. 2
    Workshoptag bei euch
    Setup, Patterns und erste Tests im Team
  3. 3
    Praxistag optional
    Tests im eigenen Projekt und in CI
Roland Golla
Roland Golla
Fullstack Developer
Zum Cypress Workshop arrow_forward

PHP 8.2 End of Life mit NCA richtig einordnen

Wir bringen PHP Anwendungen seit über 20 Jahren von einer Version zur nächsten. Unser Alltag ist Symfony und Sulu in Production, abgesichert mit PHPUnit, PHPStan, Psalm und Rector in GitHub Actions und GitLab CI. Gehostet wird auf Servern in Deutschland, und als Open Source Aktivisten kennen wir die Migrationspfade aus der täglichen Arbeit, nicht aus Folien.
Für euer Upgrade weg von PHP 8.2 übernehmen wir die Umstellung im NCA PHP Update, automatisiert mit Rector PHP und geprüft mit PHPStan. Ist der Code über Jahre gewachsen, helfen das PHP Refactoring und die Legacy Modernisierung. Die passende Pipeline baut unser CI CD Setup mit Docker und Staging.

Was nach dem Support Ende passiert

Jede PHP Version bekommt zwei Jahre aktiven Support mit Bugfixes und danach zwei Jahre nur Sicherheitsfixes. Am Ende dieser vier Jahre ist Schluss. Der Server fällt nicht aus, und eure Seite bleibt online. Das Risiko wächst still im Hintergrund.
  • Keine Patches mehr: Eine neue Lücke in PHP 8.2 wird vom PHP Team nicht mehr geschlossen.
  • Pakete ziehen weiter: Frameworks und Bibliotheken heben ihre Mindestversion an. Neue Releases installieren sich auf 8.2 nicht mehr.
  • Hosting ändert sich: Viele Anbieter nehmen alte Versionen aus dem Angebot oder stellen automatisch um. Das passiert dann nach deren Zeitplan, nicht nach eurem.
  • Audits werden schwer: Sicherheitsprüfungen und Kunden fragen nach unterstützter Software. Ein End of Life Stack fällt dort auf.
Wie das in der Praxis aussieht, zeigt PHP 8.1. Es hat Ende 2025 sein End of Life erreicht. Seitdem gibt es keine offiziellen Releases mehr dafür.

Support Daten aller aktuellen PHP Versionen

Version Aktiver Support bis Sicherheitsfixes bis
PHP 8.2 31. Dezember 2024 31. Dezember 2026, danach End of Life
PHP 8.3 31. Dezember 2025 31. Dezember 2027
PHP 8.4 31. Dezember 2026 31. Dezember 2028
PHP 8.5 31. Dezember 2027 31. Dezember 2029
PHP 8.6 Release geplant am 19. November 2026 Wird mit dem Release festgelegt

Warum PHP2Shell den Druck erhöht hat

Mit PHP 8.2.35 und den passenden Releases der anderen Zweige hat das PHP Team zwei kritische Lücken geschlossen, bekannt als PHP2Shell, beide mit CVSS 9.2 bewertet. Angreifer konnten damit ohne Login Code auf dem Server ausführen.
Genau das ist der Punkt: Heute bekommt PHP 8.2 so einen Fix noch. Nach dem End of Life nicht mehr. Für das bereits beendete PHP 8.1 gab es bei PHP2Shell nur noch Patches zum Selberbauen und Pakete von Distributionen, aber kein offizielles Release. Eine ähnliche Lücke nach dem Support Ende würde PHP 8.2 genauso treffen. Hintergründe stehen im NCA Blog zum PHP2Shell Exploit.

Die richtige Zielversion nach PHP 8.2

Die Zielversion entscheidet, wann ihr das nächste Mal ran müsst. Zwei oder drei Versionen auf einmal zu überspringen ist völlig normal. Die Arbeit bleibt dieselbe: Ihr lest die Änderungen jeder übersprungenen Version und lasst eure Tests laufen.
  • PHP 8.3 ist der kleinste Sprung. Es bekommt aber schon nur noch Sicherheitsfixes und endet Ende 2027. In einem Jahr steht ihr wieder hier.
  • PHP 8.4 bringt Sicherheitsfixes bis Ende 2028. Sein aktiver Support endet zusammen mit dem Support für PHP 8.2.
  • PHP 8.5 ist die aktuelle stabile Version mit aktivem Support bis Ende 2027 und Sicherheitsfixes bis Ende 2029. Für die meisten Teams ist das jetzt das beste Ziel.
  • PHP 8.6 ist die nächste Version und steht kurz vor dem Release. Es passt, wenn euer Rollout erst danach ansteht und eure Abhängigkeiten nachgezogen haben. Wie das gelingt, zeigt unser Glossar zum PHP 8.6 Upgrade.

Checkliste für das Upgrade weg von PHP 8.2

1. Alle Installationen finden. Prüft php -v überall, wo PHP läuft, nicht nur auf den Webservern. CLI und PHP FPM können auf derselben Maschine unterschiedliche Builds sein. Dazu kommen Cronjobs, Queue Worker, Docker Base Images und die Images eurer CI.
2. Abhängigkeiten prüfen. Composer zeigt, welche Pakete eine Zielversion blockieren. Aktualisiert diese Pakete noch auf PHP 8.2, dann bleibt der Versionswechsel klein.
Code:
          

composer prohibits php 8.5
composer audit

3. Migrationsguides lesen. Das PHP Handbuch hat für jede Version einen Guide mit allen inkompatiblen Änderungen. Bei einem Sprung von 8.2 auf 8.5 sind das die Guides für 8.3, 8.4 und 8.5. Einen schnellen Überblick vor dem Umbau liefert PHPCompatibility.
4. Rector die Fleißarbeit machen lassen. Hebt die PHP Version in der composer.json an. Mit einem leeren withPhpSets() liest Rector die Zielversion von dort und schreibt Syntax und viele Deprecations automatisch um. Startet mit einem Dry Run und prüft den Diff.
Code:
          

vendor/bin/rector process --dry-run

5. Auf der neuen Version testen. Nehmt die Zielversion als zusätzlichen Job in eure CI auf und haltet beide Jobs grün. Setzt error_reporting auf E_ALL, damit Deprecations sichtbar werden, und stellt die statische Analyse auf die Zielversion.
6. In Stufen ausrollen. composer check-platform-reqs bestätigt Version und Extensions auf den neuen Servern. Stellt erst einen Server oder einen Teil des Traffics um, beobachtet die Logs und behaltet das alte Image, bis alles stabil läuft.

Wenn eure Distribution länger Support gibt

Manche Linux Distributionen und Hosting Anbieter pflegen PHP Versionen länger als php.net. Red Hat führt die php 8.2 Streams für RHEL 8 und RHEL 9 laut Lebenszyklus bis 2029. Das ist eine echte Option, aber kein Freifahrtschein.
Vendor Support deckt nur die PHP Pakete der Distribution ab. Eure Composer Abhängigkeiten, Frameworks und CMS ziehen trotzdem weiter. Wer auf Vendor Support setzt, kauft also Zeit für das Upgrade, nicht einen Ersatz dafür. Prüft deshalb genau, woher euer PHP kommt: von der Distribution, aus einem Docker Image oder vom Hoster.

The target you pick decides how soon you'll be doing this again.

Eric L. Barnes, Gründer von PHP News und Laravel News – PHP News

Die NCA Erfahrung mit End of Life Upgrades

Ein End of Life Termin ist kein Grund für Panik, aber ein guter Grund, die Quality Gates in Ordnung zu bringen. Bei NCA kommt immer zuerst die Absicherung: PHPStan und Psalm für statische Analyse, PHPUnit für Unit Tests, der PHP Functional Test für ganze Abläufe und Cypress für die wichtigsten Nutzerwege. Fehlen Tests im Altcode, schreiben wir zuerst Characterization Tests.
Danach übernimmt Rector PHP die mechanische Arbeit, und Composer Audit prüft die Abhängigkeiten auf bekannte Lücken. Für sehr alte Systeme fördern wir den Weg aus dem Legacy heraus, etwa mit dem Strangler Fig Pattern und einem Anti Corruption Layer. Lokal arbeiten wir mit DDEV oder Docker, sodass jede Zielversion in Minuten startet. Abgerechnet wird transparent: kostenloses Kennenlernen, Aufwand schätzen, minutengenau abrechnen.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere PHP Consultant Spezialisten

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.

Häufige Fragen zum PHP 8.2 End of Life

Die wichtigsten Antworten zu Datum, Risiken, Zielversion und Upgrade weg von PHP 8.2.
Wann ist das End of Life von PHP 8.2 im Jahr 2026?

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.

Läuft meine Website 2026 nach dem End of Life von PHP 8.2 weiter?

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.

Auf welche PHP Version sollte ich 2026 von PHP 8.2 wechseln?

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.

Wie viel Zeit brauche ich 2026 für das Upgrade von PHP 8.2?

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.

Was hat PHP2Shell 2026 mit dem PHP 8.2 Support Ende zu tun?

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.

Kann ich mehrere PHP Versionen auf einmal überspringen?

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.

Hilft Rector beim Upgrade von PHP 8.2?

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.

Wie prüfe ich, welche PHP Version auf meinem Server läuft?

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.

Gibt es nach dem End of Life noch Support von Linux Distributionen?

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.

Was passiert mit WordPress Seiten auf PHP 8.2?

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.

Muss ich bei einem PHP Upgrade auch Docker Images anpassen?

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.

Was kostet ein PHP Upgrade von 8.2 bei NCA?

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.