PHP 5 hat sich gerade in der Entwicklergemeinde etabliert, da wird auch schon über den Nachfolger gesprochen und spekuliert. Internet Professionell trägt die Fakten aus der PHP-Community zusammen.

Mit PHP 5 ist den Entwicklern vor allem in Sachen Objektorientierung ein Quantensprung gelungen. Die Frage ist also, was in einer Version 6 passieren soll. Anfangs gab es dazu nur ein paar Gerüchte und viele widerstreitende Meinungen. Rasmus Lerdorf, der PHP-Erfinder, begann die Diskussionen um die neue Version im August 2005 mit einer Mail in der internen Mailingliste für PHP-Entwickler. Dabei ging es vor allem darum, einige alte Zöpfe abzuschneiden und wichtige Neuerungen in Gang zu bringen. Die schon lange geplante Unicode-Integration stand zu diesem Zeitpunkt auch schon als Aufgabe fest.

Die auf diese Mail folgende Diskussion gipfelte dann in einem Treffen der Kernentwickler in Paris im November 2005. Die hierzu von Derick Rethans verfasste Zusammenfassung ist nach wie vor in den meisten Punkten aktuell, denn dort wurden in vielen Punkten bereits Entscheidungen getroffen. Andere Fragen wie beispielsweise Namespaces für die Objektorientierung werden dagegen immer noch auf der internen Mailingliste diskutiert.

Alte Zöpfe

Die wichtigsten Vorschläge von Rasmus Lerdorf gingen dahin, einige der alten Zöpfe abzuschneiden, die PHP schon seit mehreren Versionen mit sich herumschleppt, ohne dass sich positive Effekte daraus ergeben haben. Allerdings wurden viele davon bisher noch nicht abgeschaltet, da sonst die Abwärtskompatibilität verloren geht. Für PHP 6 wurde nun auch von den übrigen Entwicklern mit entschieden, auf welche Funktionen und Konfigurationseinstellungen verzichtet werden kann.

Eine problematische Einstellung ist die php.ini-Einstellung register_globals. Sie erlaubt - wenn auf on geschaltet, unter anderem noch den Zugriff auf POST- und GET-Werte sowie Cookies per Variablenname. Heißt das Formularfeld also eingabe, steht der Wert als $eingabe zur Verfügung. Das ist aber in bestimmten Szenarien gleichzeitig ein Sicherheitsproblem. Deswegen wurden in PHP 4 zuerst die globalen Variablen $HTTP_*_VARS eingeführt, wobei das Sternchen den Ursprung des Werts angibt und dementsprechend für GET, POST et cetera steht. Diese Variablen werden in PHP 6 allerdings auch entfernt, und damit verschwindet auch die zugehörige Konfigurationseinstellung register_long_arrays aus der php.ini. Das heißt, in PHP 6 ist nur noch die superglobale Alternative $_GET beziehungsweise $_POST möglich.

Ein weiterer alter Zopf ist der safe_mode und alle zugehörigen Einstellungen. Ursprünglich wurde er eingeführt, um in Shared-Hosting-Umgebungen für Sicherheit zu Sorgen. Er überprüft, ob der Eigentümer eines Skripts auch der Eigentümer einer zu bearbeitenden Datei ist. Das ist beispielsweise ein Problem, wenn eine Datei per FTP hochgeladen wurde und der Nutzer der Datei damit der FTP-Nutzer ist, während das Skript als Webnutzer läuft. Auf den safe_mode soll dementsprechend vor allem zu Gunsten von open_basedir verzichtet werden. Mit dieser Einstellung kann der Serveradministrator den Skriptzugriff auf ein Basisverzeichnis beschränken.

Die dritte bekannte Konfigurationseinstellung ist die magic_quotes-Familie. Sie wurde eingeführt, um Nutzereingaben zu filtern. Hier wird beispielsweise einem einfachen oder doppelten Anführungszeichen, das der Nutzer per GET, POST oder Cookie übermittelt (Einstellung magic_quotes_gpc) ein Backslash vorangestellt. Das Ziel ist, sicherheitskritische Angriffe wie SQL-Injection zu vermeiden. Leider erfüllen die Konfigurationseinstellungen ihren Zweck nicht wirklich: Zum einen sind sie umgehbar, zum anderen werden die Filterungen vor dem Ausführen des Skripts angewendet und der Entwickler hat darüber keine Kontrolle. In PHP 6 sollen diese Pauschalkonfigurationen deswegen verschwinden und durch die optional einsetzbaren Eingabefilter ersetzt werden. Diese basieren auf der schon für aktuelle PHP-Versionen verfügbaren filter-PECL-Erweiterung (pecl.php.net/package/filter), die bereits seit Version 5.2 bei PHP mit dabei ist.

Bei allen drei Konfigurationseinstellungen soll in PHP 6 beim Start von PHP ein E_CORE_ERROR entstehen. Die Funktionalität selbst verschwindet komplett. Während also von PHP 4 zu PHP 5 die Migration bei der Objektorientierung etwas weh tat und tut, wird in PHP 6 die Übernahme der Uralt-Skripts schmerzhaft. Um allerdings ehrlich zu sein, diese alten Zöpfe müssten eigentlich jetzt schon abgeschnitten werden. Und auch die Entscheidung, die Zend-Engine-1-Kompatibilität zu entfernen, ist sehr verständlich. Sie diente eigentlich nur der Abwärtskompatibilität beim Kopieren von Objekten und wurde kaum praktisch eingesetzt.