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.

Traits

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??!?).