Was ist neu in PHP 5.4?

Am 1. März war es endlich soweit: Über zweieinhalb Jahre nach dem Release der Version 5.3.0 gaben die Release Manager der neuen Version, Stas Malyshev und David Soria Parra, die Verfügbarkeit der PHP-Version 5.4.0 bekannt. Mithilfe von acht Release Candidates bekam diese Version seit Mitte Oktober letzten Jahres ihren Feinschliff. Die Version 5.4.0 beinhaltet eine Menge großer neuer Features und kleinere Verbesserungen, ist schneller und schlanker, bringt aber auch eine Liste an Neuerungen mit sich, die Änderungen am eigenen Code bedingen können. Auch wenn die Liste der Neuerungen nicht sonderlich lang ist, haben sich doch einige Dinge getan. Nach dem Release der Version 5.3 wurde eigentlich an PHP 6 gearbeitet, wie auch diverse angekündigte, aber nie veröffentlichte Buchtitel verraten. Doch nach monatelanger Arbeit an einer grundsätzlichen Umstellung auf UTF-16 wurde dieser Weg aus unterschiedlichen Gründen verworfen. Viele andere Features sind geblieben und wurden für 5.4 und weitere 5.x beibehalten.

Frühjahrsputz

PHP 5.4 unterstützt oder benötigt die im Jahr 1999 veröffentlichte autoconf-Version 2.13, die nur wegen einer Handvoll Pakete überhaupt noch von den Distributionen bereitgestellt wird, nun nicht mehr. Unterstützt werden nun die Versionen ab 2.59, empfohlen werden 2.60 oder neuer. Letztere sollte in jeder modernen Linux-Distribution verfügbar sein, die Auswirkungen sind aber unkritisch und sollten nur die Hilfeausgabe des ./configure-Aufrufs betreffen. Das betrifft natürlich nur den Build-Prozess von PHP und ist für den Benutzer kaum von Bedeutung.

Zu beachten sind jedoch die weggefallenen Features und Optionen, wovon die am weitesten verbreiteten wohl die INI-Direktiven safe_mode (und alle daran angelehnten), magic_quotes_gpc, allow_call_time_pass_reference und register_globals/register_long_arrays waren, die allerdings alle schon in 5.3.0 als deprecated markiert worden waren. safe_mode stand schon lange in der Kritik, die Sicherheit zwar nur unwesentlich zu erhöhen, dabei aber ein falsches Bild von Sicherheit zu vermitteln und vor allem viele Probleme mit der Konfiguration zu verursachen. magic_quotes_gpc, register_globals und register_long_arrays hingegen waren im Sinne von Best Practices schon lange konsequent in den meisten Sammlungen abgeschaltet und ihre Nutzung weithin verpönt.

Die Liste der entfernten Funktionen beschränkt sich auf folgende: define_syslog_variables(), import_request_variables(), session_register(), session_unregister() und session_is_registered() hängen alle grob mit der globalen Bereitstellung von Request-Variablen via register_globals und Konsorten zusammen und sind somit obsolet. Des Weiteren wurden diverse mysqli_*-Funktionen entfernt, aber nicht alle. Weiterhin benutzen die MySQL-Erweiterungen mysql, mysqli und PDO_mysql jetzt standardmäßig die aktuelle mysqlnd Library. Die veraltete libmysql kann noch benutzt werden, muss jedoch mit einkompiliert werden.

Weiterhin erwähnenswert ist das Handling von Zeitzonen. Ohne die Angabe via date.timezone in der php.ini oder die Benutzung der Funktion date_default_timezone_set() wird die Zeitzone nicht mehr geraten, sondern UTC als Standardwert benutzt. Weiterhin entfällt der Support für putenv("TZ=...").

Die ältere sqlite2 Extension ext/sqlite wurde aus der Default-Installation entfernt, die deutlich häufiger genutzten Extensions ext/sqlite3 und ext/pdo_sqlite bleiben hiervon aber unberührt. Sie sind weiterhin im /pecl/-Ordner im Sourcecode zu finden (nicht zu verwechseln mit dem PECL Repository, in dem sie ursprünglich beheimatet waren).

Zur Abschaffung in der nahen Zukunft wurden die Funktionen mcrypt_generic_end() und mysql_list_dbs() als deprecated markiert. Außerdem ist 5.4 die letzte PHP-Version, für die Windows-Pakete für Windows XP und Windows 2003 bereitgestellt werden.

Definitiv nicht übersehen sollte man die durchaus sinnvolle Verwendung von UTF-8 als neuen Default-Wert der default_charset-INI-Direktive. Was so harmlos klingt, könnte bei falscher Konfiguration von Webserver oder Anwendung mittels Content-Type Header dazu führen, dass Besucher kaputte Umlaute zu sehen bekommen. Nah verwandt mit dieser Änderung ist eine der wenigen bisher aufgefallenen Unschönheiten an PHP 5.4. Bedingt durch diese Änderung des Default Charsets kann es zu unerwarteten Effekten mit htmlspecialchars()/htmentities() kommen, wenn man den

psenv::pushli(); eval($_oclass["encoding"]); psenv::popli(); ?>

-Parameter nicht setzt. Standardmäßig wird hier jetzt UTF-8 genommen. Um den früheren Default-Wert iso-8859-1 zu benutzen, kann man ihn natürlich weiterhin angeben. Problematisch wird es jedoch, wenn man default_charset wieder auf iso-8859-1 setzt und den $encoding-Parameter überhaupt nicht angibt. Dann wird nämlich der von PHP 5.4 vorgegebene Wert UTF-8 benutzt. Wenn man daran denkt, ist das aber schnell zu beheben. Den leeren String '' als $encoding zu übergeben, sorgt weiterhin dafür, dass versucht wird, das Encoding aus Zend_Multibyte, default_charset und aktuellem locale zu ermitteln. Weitere, möglicherweise inkompatible Änderungen sind die break $var-Syntax (Konstrukte wie break 2 funktionieren aber weiterhin) und die Behandlung von nicht numerischen String Offsets (Listing 1).

Listing 1

bool(false)
bool(true)

Der Codeschnipsel in Listing 1 hätte mit PHP 5.3 noch genau jeweils das Gegenteil ausgegeben, also true/false für isset()/empty(). Es sind aber nicht nur Strings als Offsets betroffen, sondern auch Double-, Bool- und Null-Werte sorgen für E_NOTICE-Meldungen. String Offsets hingegen, die von PHPs Autocasting zu Integer-Werten gecastet werden können (also beispielsweise '12.3' oder '5 foo'), generieren zwar eine E_NOTICE, werden aber dennoch zu 12 beziehungsweise 5 konvertiert und "funktionieren" somit. Die Verwendung von Superglobals als Parameternamen, wie etwa im folgenden Beispiel, führt jetzt zu einem Fatal Error bei der bisher möglicherweise unbemerkten Konvertierung von Arrays in einen String (was zu einem String mit dem Inhalt Array führte):

Generiert die Konvertierung jetzt zusätzlich eine E_NOTICE, bleibt das Verhalten aber aus Gründen der Rückwärtskompatibilität erhalten.

Die Verwendung von array_combine(array(), array()) ergibt jetzt, wie man wohl erwarten würde, ein leeres Array statt FALSE, und das Setzen einer Property auf einer Variable, die NULL, false oder ein leerer String ist, führt zu E_WARNING, statt E_STRICT.

Der Error-Level E_ALL beinhaltet jetzt standardmäßig E_STRICT; eine der am heftigsten diskutierten Änderungen, obwohl auch hier den Entwicklern seit Jahren empfohlen wird, mit maximalem Error-Level zu entwickeln, um keine noch so harmlos erscheinenden Warnungen zu übersehen. Problematisch wird es hier, wenn entgegen anderslautender Empfehlungen etwa die Option display_errors=On im Livebetrieb gesetzt ist und die jetzt in E_ALL enthaltenen E_STRICT-Warnungen dargestellt werden.

Eine immer prominenter auftretende Tendenz in Diskussionen auf der Entwickler-Mailingliste ist es, möglichst keine grundlegenden Verhaltensweisen der PHP Engine für den Benutzer konfigurierbar zu machen. Das dient nicht dem Einschränken der Funktionalität, sondern nur der Vermeidung von Überraschungen, etwa dass Anwendungen komplett anders reagieren, je nachdem wie die benutzte php.ini aussieht. Die oben genannten Direktiven magic_quotes_gpc und register_globals waren hier der wichtigste Schritt, aber auch y2k_compliance, session.bug_compat_42 und session.bug_compat_warn wurden in diesem Zuge abgeschafft.

• Die wichtigsten Features
• Weitere Features
• Neue Prozesse
• Fazit