It’s simple and elegant, since PHP 5.4 introduced short array syntax:

$everySingleArrayInitializationFromNowOn = [];

Why this step? An alarming large amount of websites still runs on PHP 5.3, which does not get updated anymore since 2014/08/14, after one year of “security only” support. In other words, the next critical security hole will only be fixed for versions above 5.4. By the way, active development of the PHP 5.4 branch was discontinued on 2014/09/14. it’s already in the “security only” phase. On 2014/08/28, PHP 5.6 has been released, on 2013/06/20, almost 1.5 years ago, PHP 5.5.

So, by now, in the year 2014 everybody should work on PHP 5.5, right? That’s the theory, in practice it looks like this:



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

Almost half of the Alexa Top 1M Sites that run on PHP, state the version 5.3, ca. one quarter even 5.2, which is not supported since Jan. 2011. PHP 5.2.17 even is the most used patch version in this statistic.

There are probably many reasons:

“never touch a running system” mentality

Not or not sufficiently maintained servers

Incompatible frameworks and legacy applications

I want to go into some background briefly.

Debian

Debian Linux follows a philosophy with its stable releases, that only established packages that were put to the acid test are included and thus is usually 1-2 minor versions behind. But Debian has a special role since security paches from current versions are still applied. The current oldstable Debian 6 (“Squeeze”) was shipped with PHP 5.3.3 and patched continuously until end of security support on 2014/03/31. Thus, according to the statistic, 5.3.3 is the most common patch version of 5.3. Debian Squeeze is planned to receive “Long Time Support” (LTS) until Feb. 2016, a new concept with a team of volunteers (see https://wiki.debian.org/LTS/). We wil see if this results in PHP 5.3.3-debian being securiry wise up to date.

The current stable version Debian 7 (“Wheezy”) comes at least with PHP 5.4 – whoever still works on Squeeze with 5.3.3, should check with their hoster if there are good reasons for this.

Frameworks And Legacy Code

From my daily routine with Magento I know the problem too well: The framework or application is not compatible with newer versions and either there is no corrsponsing update or plugins/extesions prevent it.

Magento for example is only since CE 1.9 (EE 1.14), released in Mai 2014, fully PHP 5.4 compatible. For versions 1.6 to 1.8 a patch came out in Jan 2014 (Patch for PHP 5.4 compatibility. But now things are moving on faster: The latest version 1.9.1 is meant to be fully PHP 5.5. compatible.

I admit, it’s even more difficult with individually developed applications and old components. But to all the “I would like to update buuuut…” people: Don’t be part of the problem, be part of the solution!

What can we do?

Developers: Test your code on current PHP versions and follow the Migration Guides, especially about Backward Incompatible Changes. Have no regard for versions whose security support ended.

Project Managers: Explain to your clients that an update is obligatory due to security reasons and it can take several days, dependent on the amount of technical dept. If they insist on staying on PHP <= 5.3, fire them or charge extra for supporting outdated versions. Hosters: Notify your clients if their server still uses PHP 5.3 or older, explain to them the importance as well and help them with the migration if needed.

Overview: What does not work anymore since PHP 5.4

Removed deprecated features:

safe_mode – security relevant code should not rely on the “safe mode” setting anymore magic quotes – another “security feature” of the “good intentions” kind. Applications that relied on this setting, urgently need a rewrite following current standards. register_globals and register_long_arrays – seriously, did anybody still use these? $HTTP_GET_VARS ? GET and POST parameters as global variables? Throw away the PHP 4 code! define_syslog_variables() and import_request_variables() – another relict, register_globals at runtime. session_is_registered() , session_register() and session_unregister() . These were replaced with the $_SESSION array in PHP 4.1(!!!) function aliases: 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() .

Other non backwards compatible changes:

mbstring.script_encoding was replaced with zend.script_encoding . call time pass by reference is not possible anymore. I.e. you cannot pass a parameter by reference with prepending & if the method signature did not define it. This is particularly interesting when useing call_user_func with references. Arguments for break and continue must be constant now. Expressions like break $var do not work anymore. The time zone must be set explicitely in php.ini or with date_default_timezone_set() . More strict handling of string offsets like $string[1] . Offsets must be numeric. Array to string conversion Notice: echo array(1, 2, 3); still results in “Array” but additionaly the notice Creating default object from empty value in Warning: I honestly did not know that it was possible but now $obj = null; $obj->var = 123; omits a warning. Superglobals like $_GET and $_POST cannot be used as parameter names anymore. Who does this anyway? salsa10 and salsa20 are not available anymore as hash algorithms. The reason is … understandable: https://bugs.php.net/bug.php?id=60783 array_combine(array(), array()) now returns array() instead of false htmlentities throws a E_STRICT error with asian character sets. The third argument of ob_start is now a combination of flags New reserverd keywords: trait, callable, insteadof

PHP 5.3 Death March

I hereby declare PHP 5.3 Death March (or should it be Death November?), a tribute to the IE 6 Death March, whose website ironically does not work anymore because of incompatibility with PHP 5.4:

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

What a cautionary tale!