Warum ich aktiv PHP 5.3 Kompatibilität aufgeben werde

Das geht ganz einfach und elegant, da in PHP 5.4 die short array syntax eingeführt wurde:

$everySingleArrayInitializationFromNowOn = [];

Warum dieser Schritt? Eine alarmierend große Zahl an Websites läuft noch auf PHP 5.3, das seit dem 14.8.2014 nach einem Jahr “security only” Support nicht mehr aktualisiert wird. Das heißt im Klartext, die nächste kritische Sicherheitslücke wird nur noch für Versionen ab 5.4 gefixt. Die aktive Weiterentwicklung am PHP 5.4 Branch ist übrigens auch am 14.9.2014 eingestellt worden, auch hier sind wir bereits in der “security only” Phase. Am 28.8.2014 ist PHP 5.6 released worden, am 20.6.2013 also vor fast 1,5 Jahren PHP 5.5

Im Jahre 2014 sollten wir also alle längst auf PHP 5.5 arbeiten. Soweit die Theorie. In der Praxis sieht es leider so aus:

Quelle: http://blog.pascal-martin.fr/post/php-versions-stats-2014-10-en

Fast die Hälfte der Alexa Top 1M Sites, die auf PHP laufen, geben noch die Version 5.3 an, knapp ein viertel sogar noch 5.2, das seit Januar 2011 nicht mehr supported wird. PHP 5.2.17 ist sogar die am meisten in der Statistik auftauchende Patch-Version.

Gründe gibt es vermutlich viele:

• “never touch a running system” Mentalität
• Gar nicht oder nicht ausreichend gewartete Server
• Inkompatible Frameworks und Legacy Anwendungen

Auf einige Hintergründe will ich kurz eingehen.

Debian

Debian Linux verfolgt mit seinen stable releases die Philosophie, dass nur auf Herz und Nieren getestete und bewährte Pakete aufgenommen werden und ist deshalb üblicherweise ein bis zwei Minor Versions im Hintertreffen. Debian nimmt dabei aber gewissermaßen eine Sonderrolle ein, da Security Patches aus aktuellen Versionen angewendet werden. Die aktuelle oldstable Debian 6 (“Squeeze”) wurde mit PHP 5.3.3 geshippt und bis zum Ende des Security-Supports am 31.3.2014 laufend gepatcht. Laut Statistik ist 5.3.3 daher auch die häufigste Patch-Version von 5.3. Debian Squeeze soll noch bis Februar 2016 “Long Time Support” (LTS) erhalten, ein neues Konzept mit freiwilligem LTS Team (siehe https://wiki.debian.org/LTS/). Ob das dazu führt, dass PHP 5.3.3-debian weiterhin sicherheitstechnisch up-to-date sein wird, bleibt abzuwarten.

Die aktuelle stable Version Debian 7 (“Wheezy”), kommt immerhin mit PHP 5.4 – wer noch mit Squeeze und 5.3.3 unterwegs ist, sollte mal mit seinem Hoster klären, ob es dafür triftige Gründe gibt.

Frameworks und Legacy Code

Durch meinen täglichen Umgang mit Magento kenne ich das Problem zu gut: Das Framework oder die Anwendung ist nicht kompatibel mit neueren Versionen und entweder gibt es noch kein entsprechendes Update oder Plugins/Extensions verhindern dieses.

Magento ist beispielsweise erst seit CE 1.9 (EE 1.14), also Mai 2014 vollständig PHP 5.4 kompatibel. Für die Versionen 1.6 bis 1.8 ist zuvor im Januar 2014 ein Patch für PHP 5.4 Kompatibilität herausgekommen. Hier bewegt sich jetzt immerhin etwas: Die neue Version 1.9.1 soll schon voll PHP 5.5 kompatibel sein.

Noch vertrackter ist es zugegeben bei Eigenentwicklungen und Uralt-Komponenten. Doch all den “Ich würde ja gerne updaten aaaber…” Kollegen möchte ich sagen: Sei nicht Teil des Problems, sei Teil der Lösung!

Was können wir tun?

Entwickler: Testet euren Code auf den aktuellen PHP-Versionen und befolgt die Migration Guides, insbesondere zu Backward Incompatible Changes. Nehmt keine Rücksicht mehr auf Kompatibilität mit Versionen, deren Security Support ausgelaufen ist.
Projektmanager: Macht euren Kunden klar, dass ein Update aus Sicherheitsgründen unbedingt notwendig ist und je nach Größe der angehäuften technischen Schulden einige Tage in Anspruch nehmen kann. Wenn sie darauf bestehen, weiterhin PHP <= 5.3 zu nutzen, feuert sie oder berechnet Zusatzaufwände durch den Support veralteter Versionen. Hoster: Benachrichtigt eure Kunden, wenn deren Server noch PHP 5.3 oder älter nutzen, macht ebenfalls auf die Dringlichkeit aufmerksam und unterstützt ggf. bei der Migration.

Übersicht: Was ab PHP 5.4 nicht mehr funktioniert

Entfernte deprecated features:

1. safe_mode – sicherheitsrelevante Funktionen sollten sich also nicht auf die “safe mode” Einstellungen verlassen
2. magic quotes – noch ein “Sicherheitsfeature” aus der Kategorie “gut gemeint”. Anwendungen, die sich darauf verlassen haben, brauchen dringend einen Rewrite nach heutigen Standards.
3. register_globals sowie register_long_arrays – ernsthaft, hat noch jemand diese Einstellungen verwendet? $HTTP_GET_VARS? GET- und POST-Parameter als globale Variablen? Werft den PHP 4 Code weg!
4. define_syslog_variables() und import_request_variables() – noch so ein Relikt, sozusagen register_globals zur Laufzeit.
5. session_is_registered(), session_register() und session_unregister(). Dazu gibt es seit PHP 4.1(!!!) das $_SESSION Array.
6. Funktions-Aliase: mysqli_bind_param(), mysqli_bind_result(), mysqli_client_encoding(), mysqli_fetch(), mysqli_param_count(), mysqli_get_metadata(), mysqli_send_long_data(), mysqli::client_encoding(), mysqli_stmt::stmt().

Sonstige nicht rückwärtskompatible Änderungen:

1. mbstring.script_encoding wurde durch zend.script_encoding ersetzt
2. call time pass by reference ist nicht mehr möglich. Man kann also nicht duch voranstellen von & einen Parameter als Referenz übergeben, wenn die Methodensignatur dies nicht vorsieht. Das ist insbesondere beim Gebrauch von call_user_func mit Referenzen zu beachten.
3. Parameter für break und continue dürfen nur noch konstant sein, Ausdrücke wie break $var funktionieren nicht mehr.
4. Die Zeitzone muss in der php.ini oder mit date_default_timezone_set() explizit gesetzt werden
5. Strengere Auswertung von String Offsets wie $string[1]. Offsets müssen numerisch sein
6. Array to string conversion Notice: echo array(1, 2, 3); gibt immer noch “Array” aus, aber zusätzlich die Notice
7. Creating default object from empty value in Warning: ich wusste ehrlich gesagt gar nicht, dass es möglich ist, aber jetzt gibt es eine Warnung bei $obj = null; $obj->var = 123;
8. Superglobale wie $_GET und $_POST dürfen nicht mehr als Parameternamen verwendet werden. Wer macht denn sowas?
9. salsa10 und salsa20 sind nicht mehr als Hash-Algorithmen verfügbar. Der Grund ist … nachvollziehbar: https://bugs.php.net/bug.php?id=60783
10. array_combine(array(), array()) ergibt nun array() statt false
11. htmlentities wirft eine E_STRICT Meldung bei asiatischen Zeichensätzen
12. Der dritte Parameter von ob_start ist jetzt eine Kombination von Flags
13. Neue reservierte Schlüsselwörter: trait, callable, insteadof

PHP 5.3 Death March

Ich rufe hiermit also zum PHP 5.3 Death March auf, ein Tribut an den IE 6 Death March, dessen Webseite ironischerweise wegen Inkompatibilität zu PHP 5.4 nicht mehr funktioniert:

Fatal error: Call-time pass-by-reference has been removed in /home/sxtxixtxcxh/iedeathmarch.org/wp-content/plugins/openid/Auth/OpenID/Server.php on line 1709

Das ist doch ein schönes abschreckendes Beispiel!