Ende Juni wurde PHP 5.3 veröffentlicht. Heute bin ich auf meinem Entwicklungs-System unfreiwillig zum Opfer der neuen Version geworden. Unfreiwillig deshalb, weil ich mal schnell ein vorgefertigtes Server-Paket namens MAMP auf einem Mac installliert habe, ohne weiter zu schauen, was da im einzelnen installiert wird. Aber es war eine heilsame Erfahrung. Ich bekam nämlich einen Heiden-Schreck – samt weißem Bildschirm und einer fatalen Fehlermeldung im PHP-Log:

PHP Fatal error:  Non-static method foo::bar() cannot be called statically, assuming $this from incompatible context in /Pfad/zur/class.php on line 285

Fakt ist, dass derselbe Code produktiv auf mehreren Webservern läuft – nur eben werkelt auf keinem von ihnen PHP 5.3. Nach einem kurzen Rundblick in diversen Foren gehe ich davon aus, dass zahlreiche verbreitete PHP-Anwendungen wie etwa das CMS Mambo mit einem ähnlichen Fehler aussteigen würden, wenn über Nacht ein Update auf PHP 5.3 vorgenommen worden wäre. Die meisten Nutzer wissen das jetzt nur noch nicht.

Mit Version 5.3 macht PHP einen Entwicklungsschritt, der mit alten Konventionen bricht und eigentlich für eine neue Versionsnummer hinter dem Dezimalpunkt viel zu groß ist. Das mag ein durchaus sauberer Schnitt sein, kann aber – wie man sieht – fatale Konsequenzen haben. Viele PHP-Projekte wurzeln noch in PHP 4. Damals wurde die Sprache zwar um Objektorientierung erweitert, aber Programmierer, die in echten objektorientierten Sprachen zuhause sind, haben dieses OOP light niemals richtig Ernst genommen.

Mit Version 5 ist PHP in Sachen Objektorientierung durchaus erwachsener geworden (und künftig mit PHP 5.3 noch mehr). Aber um der Abwärts-Kompatibilität willen brauchte sich ein PHP-Programmierer bis dato trotzdem nicht darum zu kümmern, ob beispielsweise eine Methode öffentlich deklariert wird (standardmäßig nimmt PHP 5 an, sie sei public). Oder – siehe meine Fehlermeldung – statisch. Mehr dazu im Kapitel Static Schlüsselwort im PHP-Manual.

PHP 5.3 wurde zwar am 30. Juni veröffentlicht, dürfte im Produktiveinsatz aber noch keine Rolle spielen. Ich habe zwar keine Zahlen parat. Aber ich kann mir nicht vorstellen, dass ein Massen-Hoster, der bei vollen Sinnen ist, seine Webspace-Pakete auf PHP 5.3 aufrüstet – es sei denn, er möchte die eigene Hotline mal so richtig mit verstörten User-Anfragen auslasten (oder er hat gar keine Hotline).

Meine bevorzugte Server-Distribution Debian installiert in der stabilen Version Lenny PHP 5.2.6; ein 5.3er-Paket findet sich bislang noch nicht einmal in Testing oder Unstable, sondern nur im Experimental-Zweig. Es ist also noch Zeit bis zum Umstieg. Allerdings gibt es Diskussionen unter Debian-Entwicklern, ob für die nächste stabile Version – wenn Debian seinen Release-Zyklus verkürzt, kommt Squeeze schon früher im nächsten Jahr –  der Sprung auf 5.3 angestrebt werden soll. Also läuft die Zeit langsam aus.

Darum sollte man sich langsam, aber sicher auf den Wechsel vorbereiten. Immerhin bringt PHP 5.3 dem Programmierer Namespaces, Closures und ausgefeiltere Bindungen. Und es verspricht einen effizienteren Umgang mit den Ressourcen. Eine gute Übersicht mit Beispielen findet sich auf Heise Developer. Die PHP-Macher bieten selbst eine ausführliche Migrations-Anleitung – samt einer Liste der Rückwärts-Inkompatibilitäten.

Um den eigenen Code auf 5.3-Tauglichkeit zu prüfen, braucht man die neue PHP-Version aber nicht gleich zu installieren. Es genügt, im Skript mit der Code-Zeile

error_reporting(E_ALL | E_STRICT);

die Fehler-Ausgabe einzuschalten (was ein Entwickler auf einem Testsystem im Gegensatz zum Produktivsystem m. E. immer tun sollte). Dabei ist es wichtig, neben dem bekannten Error-Level E_ALL (alle Fehler ausgeben, auch Warnungen oder Hinweise) auch den seit PHP >= 5.0 verfügbaren E_STRICT zu setzen. E_STRICT kann zur Laufzeit zukünftige Kompatibilitätsprobleme bemängeln, die – wie obiger Fehler – unter PHP 5.3 zu einem Fatal error führen, aber von E_ALL nicht notiert werden. Statt einen Fatal Error auszuwerfen, gibt PHP dann nur eine Warnung unter dem Stichwort PHP Strict Standards aus, stoppt die Abarbeitung des Scriptes aber nicht.

Falls sich nun jemand fragen sollte: Warum installiert der gute Mann nun schon PHP 5.3, obwohl er es eigentlich besser weiß? Zurzeit ist mein Entwicklungs-Rechner ein Powerbook mit OS-X Tiger (ist ja auch irgendwie Linux, nein: Darwin ist BSD). Leider lassen sich auf dem Mac PHP, Apache und MySQL nicht so kontrolliert mit Paketen installieren und pflegen wie unter Debian oder Ubuntu. Da ich zum selber Kompilieren zu faul war – bei OS-X wird man eben gern zum Mausschubser -, habe ich zum MAMP-Paket gegriffen: Einfach eine dmg-Imagedatei herunterladen und nach bequemer Mac-Art installieren, also in den Programmordner schieben, dann starten. Easy. Übrigens gibt es auch vom XAMPP-Projekt, das ich früher einmal unter Windows verwendet habe, eine OS-X-Version.

Ob MAMP oder XAMPP – beide Lösungen machen die Installation eines Webservers denkbar einfach, haben aber aus meiner Sicht denselben Makel: Sie installieren immer das Neueste von Neuen, und das ist alles andere als praxisgerecht. Siehe PHP 5.3. Im Webserver-Einsatz zählt eben nicht das Neueste, sondern das Stabilste. Es darf ruhig etwas abgehangen sein.

Klar: Weder MAMP noch XAMPP erheben den Anspruch auf einen Produktiv-Einsatz. Aber es bewährt sich, auf dem Entwicklungsrechner dieselbe Umgebung laufen zu lassen wie auf dem öffentlichen Webserver. Und wer seinen Webserver selbst mit Debian aufgesetzt hat, sollte keine Probleme haben, auf seinem Testsystem ebenfalls Debian mit dem gleichen Versionsstand zum Laufen zu bringen. Das geht auch auf einem Intel-Mac – in einer virtuellen Maschine.

Und wenn’s denn doch unbedingt ein vorgefertigtes Paket sein soll oder muss (mangels Virtualisierer für die PowerPC-Plattform) – dann empfehle ich MAMP 1.7.2. Ist zwar nicht mehr ganz neu, entspricht aber laut der leider sehr gut versteckten Release-Liste mit Apache 2.0.59, MySQL 5.0.41 und PHP 5.2.6 ganz gut den Verhältnissen da draußen in der rauen Web-Welt.