PHP-Entwickler in Essen

Ich bin Mariusz Szatkowski, Einzelentwickler aus Gdynia in Polen, und schreibe PHP-Anwendungen selbst. Ein Büro in Essen gibt es nicht. Ich arbeite remote und schriftlich, ohne Termine und ohne Telefonate.

Diese Seite handelt von einer Aufgabe: Eine PHP-Anwendung läuft auf einer Version, für die es keine Sicherheitsupdates mehr gibt oder bald nicht mehr geben wird, und sie soll auf eine unterstützte Version. Hier steht, nach welchen Quellen ich dabei vorgehe und was Sie davon selbst prüfen können, auch wenn Sie nie mit mir arbeiten.

#Welche PHP-Version wird noch unterstützt?

Das Handbuch auf php.net erklärt das Schema auf der Seite Supported Versions: Jeder Zweig wird zwei Jahre lang aktiv betreut, danach zwei weitere Jahre nur noch bei kritischen Sicherheitsproblemen. Nach vier Jahren ist er am Ende seiner Laufzeit und wird nicht mehr unterstützt.

Stand 11. November 2026 steht dort:

Auf der Seite zu den beendeten Zweigen stehen unter anderem 8.1 (Ende 31. Dezember 2025), 8.0 (26. November 2023), 7.4 (28. November 2022) und 5.6 (31. Dezember 2018). Läuft Ihre Anwendung auf einer dieser Versionen, gibt es dafür keine Sicherheitskorrekturen mehr. Bei 8.2 endet die Frist in wenigen Wochen.

Wählen Sie die Zielversion nicht nur nach dem Datum. Framework, Content-Management-System und Pakete müssen sie unterstützen. Das lese ich aus Ihrer composer.json und den Versionshinweisen der Pakete aus, bevor ich ein Ziel vorschlage.

#Die Migrationsleitfäden: wo jeder Sprung beschrieben ist

Im Anhang des Handbuchs sind die Sprünge einzeln dokumentiert, von 5.6 auf 7.0 bis zu den neueren Zweigen. Die Übersicht im Anhang führt zum Beispiel “Migration von PHP 7.4.x auf PHP 8.0.x” und “Migration von PHP 8.0.x auf PHP 8.1.x”. Jeder Leitfaden hat im Kern zwei Teile: nicht abwärtskompatible Änderungen und veraltete Features. Die zweite Liste ist die Vorwarnung für den nächsten Sprung.

Aus den Leitfäden, die ich für Altanwendungen am häufigsten brauche:

• PHP 8.0. Ein loser Vergleich zwischen einer Zahl und einer nicht numerischen Zeichenkette wandelt nun die Zahl in eine Zeichenkette um. Die Seite zeigt: 0 == "foo" war vorher wahr und ist jetzt falsch. Das ändert Verhalten, ohne dass irgendeine Meldung erscheint. Außerdem sind mehrere Ressourcen zu Objekten geworden, etwa curl_init(), das nun ein CurlHandle liefert. Prüfungen mit is_resource() sollen durch einen Vergleich mit false ersetzt werden. match und mixed sind reservierte Wörter.
• PHP 8.1. Ein optionaler Parameter vor einem Pflichtparameter gilt immer als Pflichtparameter. Der Schreibzugriff auf das gesamte Array $GLOBALS wird nicht mehr unterstützt.
• PHP 8.2. Das Anlegen dynamischer Eigenschaften ist veraltet, außer die Klasse erlaubt es mit #[\AllowDynamicProperties]. Das Handbuch empfiehlt, die Eigenschaft zu deklarieren. Bei zusätzlichen Daten an fremden Objekten nennt es WeakMap.
• PHP 8.4. Ein Parameter mit Standardwert null und einem Typ ohne ? ist als implizit nullable veraltet. Die Seite nennt die Schreibweise ?T oder T|null.
• PHP 8.5. Die Seite zu den veralteten Features führt unter anderem den Backtick-Operator, nicht kanonische Cast-Namen, null als Array-Offset und die Magic Methods __sleep() und __wakeup() auf.

Bei großem Abstand lese ich alle Leitfäden zwischen Ist-Version und Ziel. Wer von 7.4 auf 8.4 geht, liest also mindestens fünf. Die Reihenfolge der Etappen entscheide ich nach der Fehlerliste, nicht nach Schema.

#Rector: der automatische Teil

Rector setzt Umbauten automatisiert um. Nach der Dokumentation braucht Rector selbst PHP 7.2 oder neuer, kann aber Code für PHP 5.x und 8.x verarbeiten, und es arbeitet am besten mit typisiertem, objektorientiertem Code, in dem Logik und Templates getrennt sind. Das ist bei gewachsenen Anwendungen selten der Fall, deshalb rechne ich mit Handarbeit.

Für ein Upgrade ist withPhpLevel() der passende Einstieg. Nach der Seite zu den Leveln fügt Rector Regeln nur bis zu der PHP-Version hinzu, die in Ihrer composer.json steht. Der Level läuft also nie dem voraus, was die Laufzeit kann:

<?php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    ->withPhpLevel(0);

Ein Level ist die Liste der ersten N Regeln eines Sets, von der sichersten bis zur komplexesten. Ich erhöhe ihn um eins, lasse vendor/bin/rector process --dry-run laufen, lese den Diff und übernehme ihn als eigenen Pull Request. Wenn der Level alle Regeln für Ihre Version abdeckt, wechselt die Dokumentation zu withPhpSets(). Die ausführliche Arbeitsweise mit den Leveln steht auf der Seite zur PHP-Entwicklung in Bielefeld.

Was Rector nicht tut: Es kennt Ihre Fachlogik nicht. Der geänderte Vergleich aus PHP 8.0 ist ein Beispiel, bei dem sich der Code nicht umschreiben lässt, weil die Absicht dahinter fehlt. Solche Stellen suche ich zusätzlich über die Fehlerliste und die Tests.

#PHPStan: die Fehlerliste für die Zielversion

PHPStan analysiert den Code, ohne ihn auszuführen. Für ein Upgrade ist ein Parameter nützlich, den die Konfigurationsreferenz beschreibt: phpVersion. Standardmäßig nutzt PHPStan die PHP-Version, unter der es läuft. Setzen Sie phpVersion, analysiert es den Code, als wäre er für diese Version geschrieben. Seit PHPStan 2.0 geht auch ein Bereich mit min und max. Ohne Angabe liest PHPStan die Plattformversion aus der composer.json, falls dort eine steht.

parameters:
    level: 5
    phpVersion:
        min: 80100
        max: 80400
    paths:
        - src

So zeigt die Analyse, wo Signaturen und Typen mit der Zielversion kollidieren, ehe ein einziger Request auf dem neuen Server läuft. Zu den Stufen (0 bis 10) und zur Baseline, die vorhandene Fehler ausblendet, gibt es die Seite in Bielefeld, ich wiederhole sie hier nicht.

Es gibt Grenzen. PHPStan ersetzt keine Laufzeitprüfung. Die Erweiterung phpstan-deprecation-rules erkennt nach ihrer Beschreibung die Nutzung von Klassen, Methoden, Eigenschaften, Konstanten und Traits, die mit @deprecated markiert sind. Das betrifft Pakete und eigenen Code, nicht die Sprachänderungen aus den Leitfäden.

#Veraltetes im Betrieb sichtbar machen

Veraltete Sprachfeatures melden sich zur Laufzeit als E_DEPRECATED. Das Handbuch nennt das Meldungen über Code, der in künftigen Versionen nicht mehr funktionieren wird. Hier lauert eine Falle: Vor PHP 8.0 war der Standardwert von error_reporting so gesetzt, dass E_NOTICE, E_STRICT und E_DEPRECATED fehlten. Seit 8.0 ist er E_ALL. Auf einem alten Server schweigt PHP also oft zu Dingen, die auf dem neuen Server laut werden.

Meine Reihenfolge auf einer Kopie mit der Ziel-Version: error_reporting auf E_ALL setzen, Fehler in eine Logdatei schreiben, nicht auf die Seite. Die mitgelieferte php.ini-production setzt display_errors laut Handbuch auf Off, und das Handbuch warnt davor, die Anzeige auf einem erreichbaren System einzuschalten. Danach führe ich die wichtigsten Abläufe durch und lese das Log.

#Das Hosting: wo die Version tatsächlich festgelegt wird

Die PHP-Version legt in der Regel nicht Ihr Code fest, sondern der Server oder das Hosting-Paket. Drei Dinge prüfe ich, bevor ich etwas umstelle:

1. Welche Version läuft im Web? Die Funktion phpversion() liefert die Version der gerade laufenden PHP-Instanz. Sie gehört in einen Aufruf über den Webserver, nicht in die Konsole.
2. Welche Version nutzt die Kommandozeile? php -v zeigt sie, php -m die geladenen Module. Das Handbuch beschreibt, dass php_sapi_name() für die Konsole cli liefert, während der Webserver je nach Anbindung andere Werte hat. CLI und Web sind also verschiedene Schnittstellen und können auf einem Server verschiedene Versionen haben.
3. Fehlt eine Erweiterung? Ich vergleiche die Modulliste von php -m auf altem und neuem Stand. Fehlt eine Erweiterung, merkt es die Anwendung erst, wenn der betroffene Ablauf läuft.

Ein Syntaxcheck mit php -l ist schnell gemacht. Das Handbuch sagt aber ausdrücklich, dass er keine Fehler findet, für die der Code ausgeführt werden müsste, etwa undefinierte Funktionen. Er ersetzt weder PHPStan noch Tests.

Foto: Michielverbeek, CC BY-SA 4.0, Wikimedia Commons.

#Tests, wenn es keine gibt

Ein Versionswechsel ohne Tests zeigt nur, ob die Seite startet. Wie ich Tests für Code schreibe, der keine hat, steht auf der Seite zur PHP-Entwicklung in Bielefeld: Charakterisierungstests, die festhalten, was die Anwendung heute liefert, auf einer Kopie mit pseudonymisierten Daten. Für das Upgrade heißt das: erst die Tests auf der alten Version grün, dann dieselben Tests auf der neuen.

Die Abhängigkeiten sind ein eigenes Thema. Was composer.lock, composer audit und das Aktualisieren der Pakete angeht, finden Sie auf der Seite zur PHP-Entwicklung in Wuppertal. Hier nur der Zusammenhang: Das Upgrade scheitert oft nicht am eigenen Code, sondern an einem Paket, das die Zielversion nicht unterstützt.

#Was das Datenschutzrecht in Nordrhein-Westfalen dazu sagt

Zuständige Aufsichtsbehörde für Unternehmen in Essen ist die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen, kurz LDI NRW. Zwei Quellen sind für das Thema wichtig.

Art. 32 DSGVO verlangt geeignete technische und organisatorische Maßnahmen unter Berücksichtigung des Stands der Technik und nennt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung ihrer Wirksamkeit. Die LDI NRW beschreibt in ihrer Handreichung Hilfe, ein Cyberangriff! als Teil des Schutzniveaus, dass kritische Sicherheitslücken schnell erkannt und geschlossen werden (Patch-Management). Sie weist außerdem darauf hin, dass eine Datenpanne über ein Web-Formular an die LDI NRW gemeldet werden kann und dass innerhalb von 72 Stunden nach Bekanntwerden eine erste Risikoeinschätzung erfolgen muss.

Eine PHP-Version ohne Sicherheitsupdates passt schlecht zu dieser Beschreibung. Ob ein konkreter Betrieb damit gegen Art. 32 verstößt, hängt vom Einzelfall ab und ist keine Frage, die ich beantworte. Ich liefere Ihnen die technische Grundlage: welche Version läuft, bis wann sie unterstützt wird und welche Schritte offen sind.

#Checkliste vor dem Upgrade

• Welche PHP-Version läuft im Web, welche in der Konsole und im Cron?
• Welche Version nennt Ihre composer.json als Mindestversion, und was sagen die Pakete zur Zielversion?
• Gibt es eine Kopie der Anwendung mit derselben Zielversion als Testumgebung?
• Welche drei Abläufe dürfen nicht ausfallen, und wer weiß, wie sie richtig aussehen?
• Wo liegt das Fehlerlog, und wer liest es nach dem Umstellen?
• Wie sieht der Rückweg aus, wenn nach dem Umstellen etwas nicht läuft?

Lücken in den Antworten sind in Ordnung. Ich fasse sie schriftlich als offene Fragen zusammen.

#So läuft ein Upgrade mit mir

1. Anfrage schriftlich. Sie schicken mir Adresse oder Repository, aktuelle PHP-Version, Framework und Ihren Termin.
2. Bestandsaufnahme. Ich lese composer.json, die Versionsangaben und die Stellen, an denen Geld, Kundendaten oder Schnittstellen bewegt werden.
3. Umfang und Annahmen schriftlich. Dort steht die Zielversion, was dazugehört und was nicht. Kommt später Neues hinzu, bekommt es eine eigene Schätzung.
4. Umsetzung auf einer Kopie. Rector und PHPStan laufen in kleinen Schritten, jeder Schritt landet als Pull Request in Ihrem Repository.
5. Abnahme und Umstellung. Sie prüfen das Ergebnis anhand der vereinbarten Kriterien. Erst nach Ihrer Freigabe wird das Hosting umgestellt.
6. Übergabe. Ein README mit den geänderten Stellen, die Liste der Auffälligkeiten und die Hinweise für den Rückweg.

Gestaltung, Mockups und Grafik kommen von Ihnen. Das Upgrade ändert nichts am Aussehen.

#Häufige Fragen

#Auf welche PHP-Version sollte ich heute upgraden?

Nach php.net (Stand 11. November 2026) erhält PHP 8.2 nur noch bis 31. Dezember 2026 Sicherheitsupdates. PHP 8.3 läuft bis 31. Dezember 2027, PHP 8.4 bis 31. Dezember 2028 und PHP 8.5 bis 31. Dezember 2029. Wer ohnehin umbaut, wählt in der Regel die neueste Version, deren Zeitplan zum Projekt passt. Ob Ihr Framework und Ihre Pakete sie unterstützen, lese ich vorher aus Ihrer composer.json aus.

#Muss ich jede PHP-Version einzeln durchlaufen?

Das PHP-Handbuch beschreibt jeden Sprung einzeln, etwa von 7.4 auf 8.0 oder von 8.0 auf 8.1. Ich lese bei einem großen Abstand alle Leitfäden dazwischen, weil Änderungen aus mehreren Stufen zusammenwirken. Ob die Anwendung dann in einem Zug oder in Etappen umzieht, entscheiden die Tests und die Fehlerliste.

#Findet Rector alle Probleme beim Upgrade?

Nein. Rector schreibt Code automatisiert um, aber nur dort, wo es eine Regel dafür gibt. Das Verhalten zur Laufzeit, etwa die geänderten Vergleiche zwischen Zahlen und Zeichenketten seit PHP 8.0, prüft Rector nicht. Deshalb folgen auf jeden Lauf PHPStan und die Tests.

#Reicht es, im Hosting-Panel die PHP-Version umzustellen?

Das Umstellen ist der letzte Schritt, nicht der erste. Vorher prüfe ich auf einer Kopie mit derselben Version, ob die Anwendung läuft, ob alle Erweiterungen vorhanden sind und ob Cron-Jobs und Webserver dieselbe Version nutzen. Außerdem sollte der Rückweg klar sein, bevor Sie umstellen.

#Was gilt in Nordrhein-Westfalen, wenn ich eine nicht mehr unterstützte PHP-Version betreibe?

Zuständig für den Datenschutz ist die LDI NRW. Art. 32 DSGVO verlangt Maßnahmen nach dem Stand der Technik und ein Verfahren zur regelmäßigen Überprüfung, und die LDI NRW nennt in ihrer Handreichung zu Cyberangriffen ein Patch-Management als Teil des Schutzniveaus. Ob eine bestimmte Konstellation bei Ihnen genügt, ist eine rechtliche Einordnung, die ich nicht vornehme. Die technische Faktenlage liefere ich Ihnen schriftlich.

#Was ist, wenn es für die Anwendung keine Tests gibt?

Dann schreibe ich vor dem Upgrade Tests, die festhalten, was der Code heute tut. Wie das geht, steht auf der Seite zur PHP-Entwicklung in Bielefeld. Ohne diese Absicherung zeigt der Wechsel der Version nur, ob die Seite startet, nicht ob sie richtig rechnet.

#Schreiben Sie mir zu Ihrer PHP-Version

Schriftlich erreichen Sie mich über das Kontaktformular. Nennen Sie die Adresse der Anwendung oder des Repositories, die aktuelle PHP-Version, das Framework, Ihren Termin und das Hosting. Meine Antwort kommt schriftlich und enthält zuerst Rückfragen zum Stand, dann den geschätzten Umfang. Diese erste Einschätzung ist gratis. Eine Übersicht meiner PHP-Arbeit finden Sie auf der Seite PHP-Entwickler.