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!
hallo fabian, sehr guter artikel und gute argumente. die projektmanager werden wie böse gucken. 🙂
YAGNI.
Never migrate a code that just work. Until it is needed.
Claiming for security is a sham.
moving to 5.4 just for brackets? a joke.
As said on reddit, not moving for brackets, brackets for moving. Security is a real concern, we shouldn’t ignore it because the code “just works”.
Found an interesting tool: PHPCompatibility – a code sniffer for compatibility with current PHP versions.
Meh. Retaining compatibility costs nothing. (Not that I’d bother for personal projects though). Discompatibilization however will go unnoticed by the careless crowd in any case. (Or just leads to unambitious Stack Overflow postings).
The proof is in the pudding, of course. But if php.net cared just a little, they’d long adapted their otherwise pointless NIH license. A little trademark/advertisement and update clause would be all that’s necessary to eradicate outdated versions. (Eradicate! Eradicate!)
One of the things we in the PHP community should do is complain to the core developers each time they want to break backwards compatibility for frivolous reasons. Removing something because of a security issue is a valid reason, but removing something because it is not pure enough, or can be done another way, or because it does not comply with the developer’s personal preferences or style is one sure way to annoy people and cause delays in the adoption of the latest PHP version.
The core developers should be allowed to fi bugs and add new features, but they should be forbidden to remove something that works just because they don’t like it. Are you aware, for example, that for PHP 7 they plan to drop the MySQL extension for no good reason other than “you should be using the mysqli extension”? They also plan to drop support for PHP 4 class constructors simply because they want everybody to use the PHP 5 class constructors instead. Haven’t they heard of the old engineering rule which says “if it ain’t broke don’t fix it”?
The biggest obstacle in the takeup of the latest version of PHP is the arrogance and stupidity of the core developers. They are there to serve *US*, the greater PHP community. We are not here to follow their dictats.
Well unless you are deliberately going to go out of your way to either use functions that are not in 5.3 or actually check the PHP version and stop it working if 5.3 or older I guarantee your code will work fine. It is not up to us to tell our users what to do since most of them a will be using a host and not have control over what version of PHP they are on. Our job as coders is to write secure and efficient code so that we can safely say that if their site is exploited it was not through our code.
I’d be intrested in knowing how many of the old php systems were running some flavor of redhat.
They’re slow to adopt new versions of php and folks that are still using redhat for whatever reason use it because it changes predictably. They don’t leave their customers hanging. They’ve been backporting fixes to old packages for years, including php.
5.x shipped with php 5.1
6.x shipped with php 5.3
7.x shipped with php 5.4
Vielen Dank für diesen Artikel! Gerade beim Googeln darauf getroffen, weil mein Webhoster auf meine Anfrage hin sein PHP nicht updaten möchte (“würde keine Verbesserung bringen”) und noch auf 5.3.3 läuft.
So langsam mache ich mir dann doch Gedanken, den Hoster zu wechseln…