5 Reasons to Consider Upgrading Your PHP Platform

In recent years, the release cycle of PHP has become much shorter. We now have a much more controlled and well-publicised process of releases, and moving between each version is no longer a leap of faith. The newer versions have HUGE performance improvements, great features, and better security, and the software is free to use. Yet we have a very, very long tail of PHP installations on older versions (around 75% on entirely unsupported versions at this point). Many of the companies I talk to think that upgrading will be pointless and painful, but that’s not my experience of migrating PHP projects. Here are a few things you might like to think about or be aware of before you make the decisions that “not broken” is good enough for your applications.

Improved Performance

I’ve written about this before, showing the impressive decrease in relative speeds of various versions of PHP. The big improvements are in PHP 5.4+, where the execution time dropped significantly and memory usage also decreased. I have made more than one client with a “slow website” happy simply by upgrading the platform – which is pretty good economics compared to the alternatives: a rewrite or a lost client. If this upgrade was to a proprietary platform, and it cost money, and they could produce these statistics, we would bite their hand off to pay for it. So why is it so hard when it is free?

This week I also ran the benchmarks for PHP 7 for the first time … yeah, you’re going to want to keep on upgrading, trust me!

Security and Support

Versions older than PHP 5.4 are no longer supported for security fixes. If some big vulnerability is found in PHP 5.3, nobody is going to fix it and your site will be vulnerable. By using newer versions, you will always know that those kinds of problems will be taken care of, and updates will be available to you very quickly when there is a problem. For me this is the Right Thing (TM) to do, for the systems that are run for my company and also for all of our clients, even if it means investing a bit of time in getting things updated. You wouldn’t buy a windows vista laptop today, why run PHP 5.3?

The current stable versions of PHP are supported – if you come across a bug, it will get fixed. Try reporting a bug on PHP 5.2 and see what response you get to that! It’s almost 10 years old and if you like your technologies from a previous decade then I respect your choices, but we’re not fixing it now.

New Syntax

Okay so your old code probably doesn’t need new syntax if nobody is going to pay you to keep actively developing the project, but bear with me because there are a couple of good things going on here.

Firstly, the short echo syntax is available from PHP 5.4 without having to enable the short_open_tag ini setting – which is in fact totally removed. There was always a security concern with the short open tags (using <? instead of the proper <?php tags) that they were less secure and open to misinterpretation. However many projects used them because of the short echo syntax (where <?=$name?> means the same as <?php echo $name; ?>) which is just much nicer to look at in templates. Moving an older project to PHP 5.4+ means you can use the short echo in templates without allowing the short tags anywhere else – and if they exist in your project, it’s a simple find-and-replace to make them into the long form tags.

There are a bunch of other neat additions to the syntax but the one I use all the time myself is the short array syntax. It’s easiest to show an example:

$dwarves = array("Sneezy", "Grumpy", "Happy", "Doc");

$princesses = ["Jasmine", "Belle", "Elsa", "Cinderella"];

It’s a small thing but very readable – a nice addition to a project that you’re still working on.


Again, the new features are more for actively-developed projects than the first points I mentioned which apply even to projects in maintenance mode, but Traits are a key feature. Once upon a time, a long time ago, PHP’s object model was basically a joke. In the PHP 5 series, it has matured and we have brought in many elements that make OOP in PHP absolutely doable – and now all modern applications are built this way. Traits were a bit of a late arrival however as they didn’t make it in until PHP 5.4, but they’re a really great addition to the family.

If you’re not familiar with traits, they’re “compiler assisted copy and paste” – that’s the best description I’ve heard and it comes from Rasmus so I’m using it! Traits allows you to assemble fragments of code and include them in your classes, meaning that you can add resuable snippets of code to otherwise unrelated classes. This allows us to compose our classes rather than just put them together using inheritance – an approach that I call the “false parent pattern”: using a generic parent object to inject functionality into all child objects even though those child objects are unrelated. For examples, see the manual page on traits.

Built In Webserver

Since PHP 5.4, PHP has had its own webserver for testing purposes. This was a feature that I had no idea why I would want it when it was first released (we’re not supposed to like change, I feel fine about this!) – but now I use it often. It allows me to quickly serve a PHP project from my local machine to test how things look or work under a specific version of PHP but without either needing to set up virtual hosts or install alternative versions.

The main reason I mention it in this article is because I cannot imagine doing upgrades without it now – while I usually use the static analysis tools and linter to check that the code is vaguely valid, the built in webserver lets me quickly spin up a project on a given version of PHP (I compile the ones I want locally but then don’t interfere with my main installed version) and check that the application still works. For more information, I’ll refer to my previous post about the built in webserver.

Password Hashing

This would be reason 6, but in fact you don’t need to upgrade PHP at all to get the benefit of this one! PHP 5.5 has great password hashing features built into it – but they’re also available in userland for older versions of PHP. The userland version is here: https://github.com/ircmaxell/password_compat and its readme is a very good way to see how to use the library both in PHP5.5+ and when using this library for previous versions. The main advantages are:

  • Every password is encrypted to a high level (the default is bcrypt)
  • Every password is salted
  • The format includes information about the algorithm and the salt so they don’t have to be stored separately

The one gotcha: if you were storing plain md5s, you need to make your database columns wider as this generates a 60 char hash!

So why did I include this in an article about upgrading PHP? Well, if you care enough about project quality to read this far, this feature is something you can implement on all your client projects tomorrow, and I thought you might be interested :)

Upgrading PHP

I have a hard time feeling good about running my own or my client projects on older verisons of PHP. We know they are slow, insecure and unsupported, and that doesn’t seem right to me. A happy client with a faster website is well worth the investment to get things upgraded. The majority of the migrations I have done have been either no trouble, or just one or two things cropped up a lot of times across a codebase. I don’t sell migration consultancy to clients who haven’t tried to upgrade by themselves yet; usually an application will upgrade within the PHP 5 series without any major issues!

I would strongly suggest that ALL new projects ship on PHP 5.6 (or at least PHP 5.5, which is also considered stable and is available in the current Ubuntu LTS release; a good platform for many), and that everyone considers upgrading their platforms. If you’ve been left behind on PHP 5.2 or PHP 5.3, it might not be an easy upgrade but making this change will give your application a new lease of life (and did I mention it’s faster??!?).

6 thoughts on “5 Reasons to Consider Upgrading Your PHP Platform

  1. Where I work the sysadmins decided to upgrade the server, they upgraded the machine, changed the os and upgraded php from 5.3 to… php 5.3. When I protested telling them that it would be better and more secure to upgrade to at least 5.4 at the time, they told me that the new os would be RedHat and that they do backports of security fixes from the later versions of PHP. I’m not sure of how secure this aproach is, but the thing is that in many palces people won’t upgrade because of the support (backports of fixes) that os vendors offer.

    • Yeah I have heard this a lot of times but I’ve also heard the PHP internals people on the quality of those backported fixes and the issues they have with bugs reported against who-knows-what version of PHP. If anyone knows how to persuade sysadmins that the alternative repos are a great way to get PHP installed, I would love to hear that!

      • The problem for the sysadmins to upgrade to a more recent php version than the one supported by the operating system is that when php needs to be compiled manually the required libraries also need to be the most recent version.
        This will lead to manually managing dependency hell and this will make the complete OS less stable.

        While working for a PCI certified payment provider I had this discussion a lot but the sysadmins could assure me that php related security is no issue when you’re working with the latest release of your OS (at least with Debain).

        For my side projects I use alternative repos like epel and webtatic to have the latest php version.
        But keep in mind that these are no “official” releases and you don’t know exactly whats “in” or if these packages were comprised by a bad person.
        So there’s a (small) risk to get a different exploit on your system by doing it this way.

      • As a SysAdmin getting php.net to offer an official binary repository for the main Linux operating systems (Redhat, Suse, Ubuntu) rather than just source code would be the only way I would install a release outside of what the OS provider ships. It doesn’t matter how trusted a third party repo is with the community when it comes down to things like PCI and legal; formal official support is all that really matters.

        Manually compiling code massively increases the responsibility I have to take on and there is little pay-off for me or my team. ‘yum update’ compared to ‘./configure ….’ followed by sorting out support libraries that aren’t compatible and then trying to compile again and again, its becomes a total none starter.

        We only upgraded to PHP 5.4 on our systems because Redhat released a supported software collection that had 5.4 included. We’ll look at PHP 5.5 soon but as yet they aren’t offering PHP 5.6 so that isn’t even being considered.

  2. > Once upon a time, a long time ago, PHP’s object model was basically a joke.

    I completely disagree. All that a language requires to be called “object oriented” is that it supports encapsulation, inheritance and polymorphism, and as these were fully supported in PHP 4 then by definition PHP 4 *WAS* an object oriented language. All those shiny new features added in PHP 5 were not required by OO at all, therefore they can be treated as optional.

    Any programmer who is incapable of writing effective software using nothing more than encapsulation, inheritance and polymorphism is just that – incapable.

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.