Sie haben funktionierenden PHP-Code für die neueste Version geschrieben, ihn in die Produktivumgebung ausgerollt und werden mit einer Flut von Fehlermeldungen von Kunden auf veralteten Hosting-Umgebungen überschwemmt. Kommt Ihnen das bekannt vor? Syntax, die Ihnen „selbstverständlich" erscheint, führt auf PHP 7.0 zu einem fatalen Fehler. Ein Dutzend veralteter Versionen lokal zu installieren, um jedes Snippet zu prüfen, ist eine Aufgabe für einen halben Tag, sofern überhaupt möglich.

Das Problem reicht tiefer, als es den Anschein hat. Alte PHP-Versionen verschwinden aus den offiziellen Repositories, lassen sich auf modernen Linux-Kernels nicht mehr kompilieren und geraten in Konflikt mit Erweiterungen. WordPress läuft weiterhin auf Servern, bei denen der Hoster zu träge für ein PHP-Update war. In der Folge funktioniert Ihr Plugin oder Theme für Hunderte Nutzer nicht mehr, nur weil Sie ein typisiertes string-Argument oder die kurze Array-Syntax verwendet haben.

Doch es gibt ein Werkzeug, das dieses Problem in Sekunden löst: 3v4l.org, ein kostenloser Online-PHP-Code-Tester für über 300 Versionen gleichzeitig. Keine Installation, keine virtuellen Maschinen. In diesem Leitfaden zeige ich Ihnen, wie Sie Inkompatibilitäten vor dem Release aufspüren, und demonstriere praxisnahe Fehler, die wir selbst in Produktion ausgeliefert haben.

💡 Kurzüberblick:

• Fügen Sie ein PHP-Code-Snippet bei 3v4l.org ein und führen Sie es über alle Versionen hinweg aus, von PHP 4.3.0 bis zum aktuellen 8.5
• Prüfen Sie die gruppierte Ausgabe: Die Seite zeigt, wo der Code läuft, wo er Fehler wirft und wo sich das Verhalten unterscheidet
• Studieren Sie zwei klassische Inkompatibilitätsbeispiele, die WordPress-Plugins auf alten Hosting-Umgebungen zum Absturz bringen, mit Code und Links zu Live-Tests
• Vergleichen Sie alternative Prüfmethoden: Docker-Container, PHPBrew, den integrierten PhpStorm-Inspector, deren Vor- und Nachteile
• Sehen Sie sich ein EN-Video an, das den TemPHPest- und 3v4l-Workflow direkt aus VSCode demonstriert

Warum die manuelle Installation alter PHP-Versionen mühsam ist

Wenn Sie einen Linux-Server administrieren, ist Ihnen sicher aufgefallen: Alte, nicht mehr unterstützte PHP-Zweige verschwinden einfach aus den Paketmanagern. Das ppa:ondrej/php-Repository, die Hauptquelle für PHP-Pakete unter Ubuntu, warnt bei der Installation unmissverständlich:

Only supported versions of PHP for supported Ubuntu releases are provided.

Mit Stand Juni 2026 sind die offiziell unterstützten Zweige 8.2, 8.3, 8.4 und 8.5. PHP 8.1 wurde im Dezember 2025 eingestellt. PHP 7.4 ist längst Geschichte. Auf Shared Hosting und veralteten VPS trifft man jedoch weiterhin auf PHP 7.0 oder gar 5.6. Code lokal dagegen zu prüfen, ist eine echte Herausforderung.

PHPBrew war einst der Retter in der Not: Das Dienstprogramm konnte jede PHP-Version aus dem Quellcode kompilieren und mit einem Befehl zwischen ihnen wechseln. Das Projekt wird jedoch seit 2020 kaum noch aktualisiert, und PHP 5.6 auf Linux-Kernel 6.x zu kompilieren, ist mit Patches und Kompatibilitätsflags eine ziemliche Knobelei. Docker-Container sind einfacher, erfordern aber das Schreiben eines Dockerfiles pro Version, das Herunterladen von Images und beanspruchen dennoch Gigabytes an Speicherplatz.

Es gibt eine Alternative, und sie funktioniert direkt in Ihrem Browser.

3V4l.org: Ihr Online-Tester für über 300 PHP-Versionen

3v4l.org (Leetspeak für „eval") ist eine Online-Sandbox, die Ihren PHP-Code auf mehr als 300 Interpreter-Versionen gleichzeitig ausführt. Vom betagten PHP 4.3.0 bis zum neuesten 8.5. Der Projektinitiator hat jede bedeutende Version kompiliert und pflegt sie, die im Laufe der Sprachgeschichte veröffentlicht wurde.

Die Mechanik ist genial einfach: Fügen Sie ein Snippet in das linke Panel ein, klicken Sie auf eval(), und innerhalb von Sekunden erhalten Sie eine Ergebnistabelle. Die Seite gruppiert die Versionen nach Ausgabe: Grüne Zeilen bedeuten, dass der Code identisch lief, gelbe oder rote zeigen abweichendes Verhalten oder einen Fehler an. Sie sehen sofort, ab welcher minimalen PHP-Version Ihre Syntax akzeptabel wird.

Besonders wertvoll: 3v4l.org zeigt den Fehlertext für jede problematische Version an. Kein abstraktes „inkompatibel", sondern konkret Parse error: syntax error, unexpected '[' in ..., mit Angabe der Zeilennummer. Das spart Stunden an Fehlersuche.

Jeder Test erhält eine eindeutige URL; der Link kann einem Ticket angehängt, an einen Teamleiter gesendet oder als Dokumentation genutzt werden: „Hier ist der Nachweis, dass match-Ausdrücke auf PHP 7.4 fehlschlagen."

Beispiel 1: Kurze Array-Syntax, eine Stolperfalle für WordPress

Ein Entwickler schreibt in JavaScript, wechselt zu PHP und erstellt aus Gewohnheit ein Array:

1
$a = [];

Sieht harmlos aus. Auf Ihrem lokalen Rechner mit PHP 8.4 funktioniert es. Auf einem Testserver mit PHP 8.2 ebenfalls. Sie rollen es in die Produktivumgebung aus, und Kunden mit PHP 5.6 sehen eine weiße Seite.

Die kurze Array-Syntax [] gibt es erst seit PHP 5.4. Davor nur array(). Und obwohl PHP 5.4 bereits 2012 erschien, wies die WordPress.org-Statistik jahrzehntelang einen signifikanten Anteil an Installationen auf PHP-Versionen unter 5.4 aus. Die Situation hat sich inzwischen gebessert, doch WordPress-Plugins müssen weiterhin Kompatibilitätsnuancen berücksichtigen.

Führen Sie diesen Ausschnitt auf 3v4l.org aus, und Sie erhalten ein eindeutiges Urteil:

1
PHP 5.3.x and older: Parse error: syntax error, unexpected '['
2
PHP 5.4.x and newer: OK

Kein Rätselraten, kein Nachschlagen im Handbuch für jedes Konstrukt. Zeitersparnis: 30 Sekunden statt 15 Minuten Suchen nach „welche PHP-Version unterstützt die kurze Array-Syntax".

Beispiel 2: Type Hints, wenn Code auf altem PHP stillschweigend zerbricht

Typdeklarationen machen PHP strenger und vorhersagbarer. Doch die Entwicklung der Type Hints verlief ungleichmäßig, und das erzeugt eine Falle. Betrachten Sie diesen Code:

1
function handleException(Exception $e) {}
2
function greet(string $name) {}
3
function processItems(array $items) {}
4
 
5
handleException(new Exception('Test'));
6
greet("hello");
7
processItems([1, 2, 3]);

Das sieht nach drei identischen Deklarationen aus. Doch ein Test auf 3v4l.org offenbart eine Überraschung:

Die skalaren Typen string, int und bool kamen erst mit PHP 7.0, 12 Jahre nach den Klassentypen! Wenn Ihr Plugin eine Mindest-PHP-Version von 5.6 deklariert und Sie function register(string $username) verwendet haben, erzeugt das auf einem alten Hosting einen kryptischen Fatal Error:

1
Catchable fatal error: Argument 1 passed to greet() must be an instance of string,
2
string given in...

Die Meldung ist verwirrend: „must be an instance of string, string given." Der Kunde liest das als Kauderwelsch und schreibt eine verärgerte Bewertung. Der Grund ist einfach: PHP 5.6 versteht skalare Type Hints nicht und versucht, string als Klassennamen zu interpretieren.

Mit 3v4l.org fangen Sie solche Inkompatibilitäten in einer Minute ab, nicht erst nach einem Dutzend Fehlerberichten.

Alternativen: IDE, Docker und Konsolenwerkzeuge

3v4l.org deckt die meisten Szenarien der Kompatibilitätsprüfung ab, aber nicht alle. Hier ist, was sonst noch zum Arsenal gehört, mit Vor- und Nachteilen.

PhpStorm. Der eingebaute Inspector von JetBrains markiert Syntax, die mit der gewählten PHP-Version inkompatibel ist: Sie geben in den Einstellungen „PHP 7.4" an, und der Editor unterstreicht match(), typisierte Eigenschaften, str_contains(). Allerdings kostet PhpStorm Geld (Abonnement ab 99 $/Jahr), und die Prüfung ist statisch, es findet keine echte Codeausführung statt. Der Inspector zeigt nicht den Unterschied im Verhalten von array_key_last() zwischen Versionen, 3v4l.org hingegen schon.

Docker. Der flexibelste Ansatz: docker run -v $(pwd):/app php:5.6 php /app/test.php führt Code in einer exakten Umgebung aus. Aber 10 Versionen zu testen erfordert 10 Container, 10 verschiedene Images und ein Automatisierungsskript. Für die schnelle Überprüfung eines Ausschnitts ist das Overkill.

Lokales PHPBrew. Wie oben erwähnt, ist das Projekt eingefroren, und alte PHP-Versionen auf einem modernen Kernel zu bauen erfordert Flickwerk mit Patches. Im Jahr 2026 ist es einfacher, 3v4l.org zu öffnen.

GitHub Actions / CI. Eine Matrix von PHP-Versionen in der CI (zum Beispiel strategy.matrix.php: ['7.4', '8.0', '8.1', '8.2', '8.3', '8.4', '8.5']) fängt Probleme bei jedem Push ab. Das ist ein Muss für Bibliotheken, aber für WordPress-Plugin-Autoren, die in Sublime Text oder VSCode ohne CI schreiben, bleibt 3v4l.org das zugänglichste und schnellste Werkzeug.

Video: TemPHPest + 3v4l direkt aus VSCode

Die Erweiterung TemPHPest für VSCode integriert 3v4l.org in den Editor: Code auswählen, Tastenkürzel drücken und Ergebnisse für alle PHP-Versionen erhalten, ohne den Browser zu öffnen. Der Autor der Erweiterung hat eine kurze Demonstration aufgezeichnet:

Die Kombination VSCode + TemPHPest + 3v4l.org bietet ein nahezu nahtloses Erlebnis: Code schreiben, sofort die Kompatibilität prüfen, Fehler beheben. Funktioniert schneller als der Wechsel zwischen Editor und Browser.

⁉️🤔 Häufig gestellte Fragen

Ist 3v4l.org kostenlos?

Ja, vollständig. Keine Registrierung, keine Begrenzung der Ausführungen, keine Werbung. Der Dienst ist Open Source und läuft auf dem privaten Server des Erstellers. Wenn Sie ihn regelmäßig nutzen, können Sie den Autor über GitHub Sponsors unterstützen und damit Hosting- und Stromkosten mitfinanzieren.

Welche PHP-Versionen sind auf 3v4l.org verfügbar?

Alle wesentlichen Releases, beginnend mit PHP 4.3.0 (veröffentlicht 2002) bis hin zum aktuellen 8.5 (November 2025). Jedes Minor-Release bildet eine eigene Zeile in der Ergebnistabelle. Insgesamt sind es mehr als 300 Versionen. Sollte eine benötigte Version nicht in der Liste sein, ergänzt der Autor neue Releases zeitnah.

Kann man ganze Projekte testen oder nur Ausschnitte?

3v4l.org ist für isolierte Codefragmente, Funktionen, Klassen und einzelne Algorithmen ausgelegt. Sie können mehrere hundert Zeilen einfügen, jedoch ohne require und include mit Composer-Autoloading und Datenbankverbindungen. Für vollständige Integrationstests eines Projekts eignen sich Docker-Container oder GitHub Actions mit einer PHP-Versionsmatrix besser.

Ist es sicher, sensiblen Code auf einem fremden Server einzufügen?

Nein. Code auf 3v4l.org erhält eine öffentliche URL und ist technisch per Direktlink zugänglich. Nutzen Sie den Dienst nicht für vertrauliche Daten, API-Schlüssel, Passwörter oder proprietäre Geschäftslogik. Für proprietären Code starten Sie einen lokalen Docker-Container: docker run -v $(pwd):/app php:7.4 php /app/private-code.php.

Worin ist 3v4l.org besser als die integrierte IDE-Prüfung?

Die statische Analyse in der IDE (PhpStorm, PHPStan) prüft Syntax und Typen, führt den Code aber nicht aus. 3v4l.org führt das Snippet tatsächlich durch die Interpreter aller Versionen aus und zeigt die tatsächliche Ausgabe sowie Unterschiede im Verhalten von array_key_last(), json_encode() und preg_match() zwischen den Versionen. Zudem ist kein IDE-Kauf nötig, es funktioniert im Browser.

Was Sie 2026 für die PHP-Code-Kompatibilitätsprüfung wählen sollten

Für die tägliche Arbeit als Theme- und Plugin-Autor sieht das Schema so aus. Ein Snippet, das Zweifel aufwirft, geht direkt auf 3v4l.org. Ergebnis in 5 Sekunden, der Link zum Test wird an den Commit angehängt. Ein Projekt, bei dem Kompatibilität mit einem Dutzend PHP-Versionen wichtig ist, erhält eine Matrix in GitHub Actions: einmal einrichten, und jeder Push läuft automatisch. Für die schnelle Prüfung von fremdem Code vor dem Code-Review: TemPHPest in VSCode (kostenlos, integriert mit 3v4l.org).

Die wesentliche Änderung gegenüber 2020 (als die ursprüngliche Fassung dieses Materials erstmals erschien): PHP 5.6 hat die meisten Hosting-Plattformen endgültig verlassen, die Mindestanforderung ist nun PHP 7.4, und am Horizont steht PHP 8.5 mit neuen Funktionen und neuen potenziellen Inkompatibilitäten. Das Prinzip aber bleibt unverändert: Kompatibilität vor dem Release prüfen, ruhig schlafen. 3v4l.org macht diese Prüfung trivial.