PHP Version Adoption

PHP runs over 75% of all websites whose technologies are known (source: w3techs), which makes for a really REALLY long tail of users who once installed wordpress, phpmyadmin, or some other open source project that helped their business needs at the time. What they don’t do is upgrade. PHP’s current usage statistics look like this (source and raw numbers are if you want them):

PHP Version Adoption

What’s alarming about this is that the left half of this graph represents unsupported versions of PHP. PHP 5.2 has been end of life since January 2011. This doesn’t mean that you can’t use it any more, but it does mean that in terms of security updates, you are out of luck. Some distributions will try to retro-fit some of the fixes but essentially your PHP applications seem a bit lacklustre because, well, you’re using technology from 2006.

Where To Go From Here

Nobody chooses a PHP 5.2 platform, these things just happen, and I absolutely don’t mean this post as a rant – more as a way of raising the issue and trying to give some pointers for moving forward. When I work with organisations to upgrade their platforms, usually either their hosting company is living in 2006, or they have a “supported” distro which prevents them from using modern technologies, or there’s been no budget to upgrade, or … really there are lots of (really valid) excuses. However good things await in newer versions of PHP!

PHP 5.3 has actual useful OOP features! We have anonymous functions (this feature will change your life, and for JS developers especially will make your PHP make more sense), the SPL extension is more than just iterators, and the DateTime extension is fabulous and finished in PHP 5.3. Also in PHP 5.3 (released 2009, it’s not cutting edge) is the vitally important E_DEPRECATED error reporting flag. This will identify any features you are using in the current version of PHP which won’t be available in the next version – if you are on PHP 5.3, or can get there, your upgrade path gets much easier! If you have a living PHP application, I can’t recommend this move strongly enough.

PHP 5.4 has some cute new features, but whether you need them or not, PHP 5.4 has faster execution time and reduced memory footprint. Here’s the graph from some benchmarks I did between versions of PHP last month – the Y axis is the number of seconds each version took, on average, to run the benchmark script included in the PHP source tree (raw numbers are available in a gist):

PHP Performance Across Versions

Whether you want to be able to use traits or not, PHP 5.4 will improve the performance of your application and reduce your hardware costs … all you have to do is upgrade between versions of free software. Why isn’t the PHP 5.4 segment on the first graph bigger? There are some explanations, such as the lack of APC, for this version, but nothing that seem compelling to me (happy to hear your stories in the comments).

PHP 5.5 isn’t actually production-ready, as we’re still in the release candidate phase for it, but it’s probably weeks away. Look out though, a more regular release cycle for PHP means that there will be smaller incremental changes and we’ll all be upgrading PHP the same way we maintain our other software – so pretty regularly. Beyond PHP 5.3, the effort and risk in upgrading is much reduced.

The Future

In truth, the future is already here for those people on PHP 5.4 and beyond. Keeping PHP upgraded is just part of our regular maintenance workflow, and the language is progressing in regular and manageable steps. If you’ve been left behind then I strongly recommend that you start making plans for upgrading your platform, or moving to a newer one. The effort will be well worth it when your application is still evolving and performing for many years to come! If any other platform gave away such incredible improvements in features and performance for free, it would be big news. Let’s make it big news in PHP too.

15 thoughts on “PHP Version Adoption

  1. Pingback: PHP Version Adoption | LornaJane | Social-Media...

    • @Eric – I know you were asking Lorna, but I thought I’d interject. I would say that unless architecturally your application cannot be saved (and I really do mean cannot be saved, as opposed to just being a bit messy,) it is never a good idea to rewrite something if you can avoid it.

      Even if by the time you’re done refactoring, your code is unrecognisable, it’s still worth doing as you’ll retain some of the project’s learnings and history as you go. Little workarounds, bug fixes, security fixes and so on are often missed when rewriting rather than just refactoring what you already have.

  2. Hi Lorna, this is a completely tangential question but what did you use to generate the shiny histogram-style image of different PHP versions? Thanks, Simon

  3. This is more a problem of the release cycle of linux distro’s. I guess ass long as new php version do not come to lts server distro’s the upgrade path will always be slow :)

    • The problem is that PHP moves on much faster than the distros. We support two PHP versions at a time, with a year of security fixes to the outgoing one when a new version is released. If LTS versions are released more than 2.5 years apart approximately, then you’ll have either not-LTS distro or not-supported PHP at some point.

      • Which leaves anyone in the Redhat (or derived) universe perennially stuck, as they seem to take more than 2 years to release anything at all! Why does a supported Linux platform always mean one the upstream developers have long since lost interest in?

  4. Pingback: 2013 Html5 Adoption

  5. This seems about right. Great article! Almost every client of mine who complained about performance issues were still on PHP 5.2 and almost never opcode caching unless its pre-configured from cPanel or web host. I’m guilty of still using PHP 5.3 on my own server, I did upgrade to 5.4 but found that PHP 5.3 with eAccelerator to be extremely fast and since cPanel does not support 5.4 with eAccelerator it meant I had to manually recompile eAccelerator after every easyapache update. Could use APC with 5.4 but have found to be the same speed as 5.3 with eAccelerator. Now built in opcode caching for 5.5 will be faster than both 5.3 and 5.4 in most cases correct?

    • Correct! You have to enable the bytecode cache for PHP 5.5, but it’s also available as an extension through pecl for earlier versions of PHP. PHP 5.4 is marginally faster than PHP 5.5 but misses some features; PHP 5.5 was released last week and I’d recommend this as your first choice of platform.

  6. Pingback: PHP mejores prácticas - 3 artículos que no debes dejar de leer

  7. Pingback: PHP Upgrade – Part of The Regular Maintenance Workflow | Web Development

  8. Pingback: PHP Upgrade – Part of The Regular Maintenance Workflow | Servage Magazine

Leave a Reply

Please use [code] and [/code] around any source code you wish to share.

This site uses Akismet to reduce spam. Learn how your comment data is processed.