NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grünes Prüfprotokoll mit Haken und Schriftzug PHPCompatibility neben PHP 8 Schild

PHPCompatibility: Definition

PHPCompatibility ist ein Regelsatz für PHP_CodeSniffer, der Code auf Verträglichkeit mit einer bestimmten PHP Version prüft. Über den Parameter testVersion legt ihr fest, gegen welche Version oder welchen Versionsbereich geprüft wird.

Das Werkzeug meldet zwei Arten von Problemen: Sprachmerkmale, die in der Zielversion entfernt oder abgekündigt wurden, und Merkmale, die dort noch gar nicht existieren. Der zweite Fall ist wichtig, wenn Code auf mehreren Versionen laufen muss. Gepflegt wird das Projekt maßgeblich von Juliette Reinders Folmer, es steht unter der LGPL und wird über Open Collective finanziert. Vor jedem Sprung auf eine neue PHP Version ist es der schnellste Weg zu einer belastbaren Arbeitsliste.

Inhalt

PHP Upgrades mit NCA: Schnelle Hilfe vom Experten

Never Code Alone begleitet PHP Upgrades seit über 20 Jahren. Unser eigener Stack aus Symfony und Sulu läuft auf aktuellen PHP Versionen, abgesichert durch PHPStan, Psalm, Rector, PHPUnit und Cypress. Wir kennen die Stellen, an denen ein Versionssprung wirklich weh tut, und die, an denen er in Stunden erledigt ist.

Teams unterstützen wir im PHP Consulting und beim Refactoring Workshop. PHPCompatibility ist dabei nur ein Baustein: Der Regelsatz läuft auf PHP CodeSniffer, ergänzt wird er durch PHPStan und Psalm für die Typprüfung sowie Rector PHP für automatisierte Umbauten. Welche Neuerungen und Breaking Changes anstehen, zeigt der Vergleich der PHP 8 Versionen.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Installation und erster Lauf

Seit Version 10 ist Composer der einzige unterstützte Installationsweg. Der Plugin Installer registriert den Regelsatz automatisch bei PHP CodeSniffer. Vorausgesetzt werden PHP 7.2 oder neuer und PHP_CodeSniffer ab 4.0.1.

Code: 
          
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/php-compatibility

Ob die Registrierung geklappt hat, zeigt ein Blick auf die verfügbaren Standards. PHPCompatibility und PHPCSUtils sollten beide aufgeführt sein.

Code: 
          
vendor/bin/phpcs -i

Ohne Angabe einer Zielversion meldet der Regelsatz nur abgekündigte und entfernte Merkmale. Erst mit testVersion wird er wirklich nützlich. Für ein Upgrade auf PHP 8.4 sieht der Aufruf so aus:

Code: 
          
vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4

Ein Bereich prüft gegen mehrere Versionen gleichzeitig, etwa testVersion 8.1-8.4 für Code, der auf allen laufen muss. Ein offenes Ende wie 8.2- deckt alles ab dieser Version ab. Praktischer als der Parameter auf der Kommandozeile ist ein Eintrag in der eigenen Ruleset Datei, dann gilt die Einstellung für alle Aufrufe und für das CI.

Was das Werkzeug nicht findet

Ein leerer Bericht bedeutet nicht, dass der Code auf der neuen Version läuft. PHPCompatibility arbeitet auf Token Ebene, ohne Wissen über Dateigrenzen hinweg und ohne Typinferenz. Damit bleiben zwei große Klassen von Problemen unsichtbar.

Das erste sind Typfehler zur Laufzeit. PHP 8 ist bei vielen eingebauten Funktionen deutlich strenger geworden. Was früher eine Warnung war, ist heute ein fataler Fehler. Ob eine Variable an einer bestimmten Stelle jemals den falschen Typ hat, kann ein Token Scanner nicht wissen.

Das zweite sind stille Verhaltensänderungen. Wenn ein Vergleich zwischen String und Zahl in PHP 8 ein anderes Ergebnis liefert als vorher, fällt nichts aus. Der Code läuft weiter und rechnet anders. Diese Fälle sind gefährlicher als jeder Absturz, weil sie erst auffallen, wenn Zahlen nicht mehr stimmen.

Deshalb ist PHPCompatibility ein erster Schritt und kein Nachweis. Der vollständige Ablauf sieht bei uns so aus:

  • Bestandsaufnahme mit PHPCompatibility gegen die Zielversion, das ergibt die erste Arbeitsliste
  • Typprüfung mit PHPStan oder Psalm für alles, was der Scanner nicht sehen kann
  • Absicherung über Tests, bei ungetestetem Bestand über Charakterisierungstests
  • Umbau mit Rector für die mechanischen Anteile, den Rest von Hand
  • Prüfung über E2E Tests mit Cypress, weil sie Verhaltensänderungen sichtbar machen

PHPCompatibility im Vergleich zu anderen Werkzeugen

Werkzeug Findet Findet nicht
PHPCompatibility Entfernte, abgekündigte und zu neue Sprachmerkmale Typfehler zur Laufzeit und stille Verhaltensänderungen
PHPStan und Psalm Typfehler durch Inferenz über Dateigrenzen hinweg Versionsbezogene Merkmale ohne passende Erweiterung
Rector Baut Code automatisiert auf neuere Sprachfeatures um Ersetzt keine Analyse, kann unvollständig umbauen
Tests und E2E Tatsächliche Verhaltensänderungen im Ablauf Nur das, wofür ein Test existiert

Rulesets für Frameworks und Polyfills

Ein häufiges Ärgernis beim ersten Lauf sind Meldungen zu Funktionen, die im Projekt längst durch einen Polyfill bereitgestellt werden. Der Scanner sieht den Aufruf, kennt aber die Ersatzimplementierung nicht.

Dafür gibt es ergänzende Rulesets. Für die Polyfills aus dem Symfony Projekt existiert ein eigener Regelsatz, ebenso für verbreitete Bibliotheken aus dem Paragonie Umfeld sowie für WordPress und Joomla. Wer alle auf einmal verfügbar haben will, installiert das Sammelpaket.

Wichtig dabei: Diese Rulesets setzen keine Mindestversion für das Projekt. Die Angabe von testVersion bleibt in jedem Fall nötig, sonst laufen nur die Prüfungen auf entfernte Merkmale.

Bei eigenen Funktionen, deren Namen zufällig wie eine entfernte Erweiterung beginnen, hilft eine Ausnahmeliste im Ruleset. Sonst meldet der Scanner Funktionen als problematisch, die selbst geschrieben wurden und mit der alten Erweiterung nichts zu tun haben.

Im CI verankern statt einmalig laufen lassen

Der größte Fehler ist, das Werkzeug einmal vor dem Upgrade laufen zu lassen und danach nie wieder. Nach dem Sprung auf PHP 8.4 beginnt sofort der Weg zur nächsten Version, und neuer Code bringt neue Fundstellen mit.

Sinnvoll ist ein fester Platz in der Pipeline, mit einer testVersion, die auf die nächste Zielversion zeigt statt auf die aktuelle. Dann sammelt sich die Arbeitsliste für den kommenden Sprung von selbst an, statt in einem großen Block anzufallen.

Bei sehr großen Altbeständen bricht der erste Lauf oft mit hunderten Meldungen. Statt alles auf einmal zu beheben, prüft man zunächst nur neue und geänderte Dateien, etwa über die Dateiliste aus dem aktuellen Merge Request. Der Bestand wird schrittweise nachgezogen. Das gleiche Vorgehen kennen Teams schon von der Einführung statischer Analyse.

Praktisch ist auch die Unterstützung in gängigen Editoren. In PhpStorm lässt sich der Standard über die CodeSniffer Integration einbinden, in VS Code über eine Erweiterung. Dann meldet sich das Werkzeug direkt beim Schreiben statt erst im CI.

a set of sniffs for PHP_CodeSniffer that checks for PHP cross-version compatibility

– PHPCompatibility, README auf GitHub

Die NCA Erfahrung mit PHP Upgrades

Ein Versionssprung ist selten ein Sprint und fast nie ein Wochenende. Der Aufwand liegt nicht im Umbau selbst, sondern im Nachweis, dass sich fachlich nichts verschoben hat.

Die Analyse starten wir mit PHPCompatibility auf PHP CodeSniffer, ergänzt um PHPStan, Psalm und Phan. Wo die kritischen Stellen liegen, zeigen Churn PHP, PHP Metrics und PHP Mess Detector. Den Umbau übernimmt weitgehend Rector PHP, bei TYPO3 Projekten TYPO3 Rector. Abhängigkeiten prüfen Composer Audit und der Composer Dependency Analyser, Syntaxfehler findet PHP Parallel Lint in Sekunden. Abgesichert wird mit PHPUnit, Functional Tests und Cypress, vor dem Commit prüft GrumPHP.

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.

Demo Team Workshop Anrufen

Häufige Fragen zu PHPCompatibility

Die Fragen, die vor jedem Versionssprung aufkommen.

Was macht PHPCompatibility 2026 genau?

Es ist ein Regelsatz für PHP CodeSniffer, der Code gegen eine angegebene PHP Version prüft. Gemeldet werden Sprachmerkmale, die in der Zielversion entfernt oder abgekündigt wurden, und solche, die dort noch nicht existieren. Ergebnis ist eine Arbeitsliste für das Upgrade, keine Garantie für Lauffähigkeit.

Wie installiere ich PHPCompatibility 2026?

Seit Version 10 ausschließlich über Composer als Entwicklungsabhängigkeit. Der Plugin Installer muss dafür freigegeben sein, dann registriert er den Regelsatz automatisch bei PHP CodeSniffer. Vorausgesetzt werden PHP 7.2 oder neuer und PHP_CodeSniffer ab Version 4.0.1.

Warum meldet der erste Lauf 2026 fast nichts?

Weil ohne testVersion nur nach entfernten und abgekündigten Merkmalen gesucht wird. Erst mit einer angegebenen Zielversion prüft der Regelsatz zusätzlich, ob Code Merkmale nutzt, die es dort noch nicht gibt. Ohne diesen Parameter bleibt ein großer Teil der Prüfungen inaktiv.

Reicht PHPCompatibility 2026 für ein Upgrade auf PHP 8?

Nein. Das Werkzeug arbeitet auf Token Ebene, ohne Typinferenz und ohne Sicht über Dateigrenzen hinweg. Typfehler zur Laufzeit und stille Verhaltensänderungen bleiben unsichtbar. Ergänzend braucht es statische Analyse mit PHPStan oder Psalm und vor allem Tests, die den Ablauf tatsächlich durchspielen.

Wie prüfe ich gegen mehrere PHP Versionen gleichzeitig?

Über einen Bereich in testVersion, etwa 8.1-8.4 für Code, der auf allen laufen muss. Gemeldet wird dann alles, was auf einer der Versionen im Bereich Probleme macht. Ein offenes Ende wie 8.2- deckt alles ab dieser Version aufwärts ab.

Was tun bei hunderten Meldungen im Altbestand?

Nicht alles auf einmal beheben. Zuerst nur neue und geänderte Dateien prüfen, etwa über die Dateiliste des aktuellen Merge Requests. So wächst der Bestand nicht weiter, während er schrittweise aufgeräumt wird. Dasselbe Vorgehen kennen Teams von der Einführung statischer Analyse.

Warum werden Funktionen gemeldet, die ein Polyfill bereitstellt?

Weil der Scanner den Aufruf sieht, die Ersatzimplementierung aber nicht kennt. Dafür gibt es ergänzende Rulesets, etwa für die Symfony Polyfills oder für WordPress und Joomla. Diese Rulesets setzen allerdings keine Mindestversion, testVersion bleibt trotzdem nötig.

Meine eigene Funktion wird als entfernte Erweiterung gemeldet, was nun?

Das passiert, wenn ein selbst geschriebener Funktionsname zufällig mit dem Präfix einer entfernten Erweiterung beginnt. Im eigenen Ruleset lässt sich für den betreffenden Sniff eine Ausnahmeliste hinterlegen, in der diese Funktionsnamen stehen. Danach verschwindet die Falschmeldung.

Gehört PHPCompatibility in die CI Pipeline?

Ja, und zwar dauerhaft. Sinnvoll ist eine testVersion, die auf die nächste Zielversion zeigt statt auf die aktuell eingesetzte. Dann sammelt sich die Arbeitsliste für den kommenden Sprung laufend an, statt am Ende als großer Block anzufallen.

Wie verhält sich das Werkzeug zu Rector?

Sie ergänzen sich. PHPCompatibility analysiert und meldet, Rector baut um. In der Praxis liefert der Scanner die Liste, Rector erledigt die mechanischen Anteile automatisiert. Rector allein ersetzt die Analyse nicht, weil sein Schwerpunkt auf modernen Sprachfeatures liegt und nicht auf Verträglichkeit.

Läuft es auch mit Frameworks wie Symfony oder Laravel?

Ja, es prüft reinen PHP Code und ist damit unabhängig vom Framework. Für die Symfony Polyfills existiert ein eigener Regelsatz, der Falschmeldungen vermeidet. Bei Frameworks ist ohnehin zusätzlich zu klären, ob die eingesetzte Version selbst die Zielversion unterstützt.

Wie begleitet Never Code Alone ein PHP Upgrade?

Wir starten mit der Analyse, sichern kritische Bereiche über Tests ab und führen den Umbau schrittweise durch, automatisiert wo möglich, von Hand wo nötig. Am Anfang steht ein kostenloses Kennenlernen, danach schätzen wir den Aufwand und rechnen transparent nach Minuten ab.