PHP5 End-Of-Life: Are You Prepared?

p>This year there has been a lot of buzz around the concept of software nearing the end of its support period, or what is known in the business as “end of life”. Mostly this is because of the fact that PHP5.x is going to be nearing its demise as of December 31st, and website owners are being encouraged to ensure they are compatible with the latest version, which is now PHP7. 

Many customers are being caught off-guard by this, even though the announcement happened quite some time ago. I think that the perspective on this update is a bit more pronounced because of a variety of reasons. First, the idea of a version 5 to version 7 upgrade sounds severe. To many, it seems like a major jump that they should be concerned about. (However, keep in mind that in this case, there was no PHP 6!) Secondly, PHP powers so much software on the web today that the issue is pretty widespread. In fact, studies show that almost 80% of identifiable web servers are utilizing it. If you use WordPress, Drupal, Joomla, Magento, or any of the other popular software platforms readily available, you have some level of exposure to PHP.

Given the hysteria that clients are exhibiting about this changeover, I figured it was worthwhile for us to again review end-of-life, look into the PHP issue in particular, and assuage some fears that you may experience around this issue.

First: The Sky Isn’t Falling!

The first point I want to impress upon you is that end-of-life doesn’t mean quite what it sounds like… Your software isn’t going to stop working on January 1st of 2019. So, enjoy your champagne as the ball drops and sleep in if you desire because your site or application won’t blow up. To explain why, let me dig into what end-of-life really means. For all software, whether commercially licensed or open-source, there is a centralized team or organization that oversees its development and ongoing support. With open-source software, an organized community assumes this role. In the case of PHP, the community set two dates around support levels offered for PHP 5.x. First, it stopped improving the software back in January of 2017. This means that there were no further incremental changes to the platform since then (view this document for a detailed schedule). However, from January 2017 until December 31, 2018, the community was updating PHP 5.x (the last release) whenever a security concern such as a vulnerability was uncovered. This means that in the 24-month span of additional coverage, the community was issuing updates in response to core security concerns. End-of-life in the case of PHP 5.x simply means that such security updates will no longer be issued -  from January 1st and on, operators of PHP 5.x are on their own.

But… Should You Worry?

Well, ideally anyone utilizing PHP 5.x or earlier is either already upgraded or planning on how they will complete the upgrade. If you are using platforms such as WordPress, Drupal or any of the systems I mentioned above, you are most likely already compatible. So, no worries there, at least for the most part. Chances are you are not only up to date, but your web host was updated as well and you didn’t even notice or missed the notifications. All is good in this instance!

However, folks who have invested in custom software built anytime before 2018 and utilizing PHP should potentially be concerned, especially if they have not invested in updating previously. The prospect of software being used in production environments that can possibly be intruded upon is not a good thing. Seeing how custom software typically carries some level of complexity, and oftentimes includes valuable user data or conducts transactions utilizing live payments – there is ample reason to be concerned about not keeping your software up to date.

What Could Happen

So, what’s the worst that can happen? Well, it is all speculation, but the most likely scenario is that a vulnerability could be uncovered which would render you at risk for intrusion or similar. Again, I tell you that this is pure speculation. You can review the history of security flaws and fixes yourself to get a sense of historical issues and when they were solved.

I think the biggest risk is that oftentimes, security flaws are found by the community, addressed by the community, and then updated accordingly. Site owners typically do not suffer the repercussions of these flaws because they attend to them quickly. In the case of software no longer being supported, if you were to be compromised you may not know for quite some time until the situation is more severe or a real loss occurs. That is something to worry a bit about – even the best system administrator will only find an issue AFTER a breach occurred if no one is releasing updates to the software.

Now, this isn’t meant to scare anyone, but rather to give you a sense of what can happen. This entire scenario is a risk vs reward calculation. Only, there really isn’t any reward here other than saving time, effort and money on an upgrade. That’s right – eventually, you’ll have to deal with this one way or another.

What Should You Do?

First, you need to understand what your current situation is from a technology perspective. Many customers who have custom developed applications have not kept up-to-date on server updates, upgrades and security patches. You could be looking at a significant server upgrade and software cleanup project. The best way to start is to contact your original developer. They can at the least give you an idea of what you have in place today.

If you are no longer working with that team, then you should work to contact someone who can determine your server environment and evaluate your code to see the level of compatibility. PHP 7 did introduce coding changes, especially in some key areas of functionality, so it is essential that you dig as deeply as possible to understand what will happen when you upgrade the software. As an example, if you upgrade your server to PHP 7 and your code isn’t compatible, you’ll instantly notice that some functionality will cease to work. This would be a catastrophic problem, so you have to ensure your system administrator and development team work together to troubleshoot and issue the appropriate fixes.

You May Be Forced To Act!

We’ve already seen some instances where web hosts have upgraded PHP underneath their customers with just a bit of advanced warning. I can’t really blame the hosts, as it would be a liability issue to not upgrade. We’ve seen this more often with shared web hosts – environments where more than one site or application is on a server. Dedicated servers and virtualized instances are less likely to suffer from this particular fate. If your web host has notified you of this upgrade, you MUST act to make sure your software will work. When their upgrade is done, your site or application could be rendered useless while you make the necessary repairs and adjustments.

What Goes Into an Upgrade?

As I had mentioned above, there are two parts to this upgrade. First, the server software must be upgraded from PHP 5.x to PHP 7.x. This happens on the server level itself. Administrators update the platform and relaunch the web services. In all, this is the easiest part of the process. However, when that software is live, the trouble can start to quickly present itself.

PHP as a language underwent changes from 5.x to 7.x. Some of the old code was “deprecated”, which means eliminated. As such, applications written using the old syntax will most likely immediately stop working when launched in a PHP 7.x environment. This means, as I’ve mentioned above, that your core application code must be reviewed and tested to ensure compatibility.

What goes into this and what it will cost you depends on a variety of factors. Was the code assembled using a coding framework? Over the years was it kept up to date? Has technical debt accrued during years and years of iterative adjustments? The bottom line is, it’s hard to predict what you’ll be investing into this upgrade because each situation is different. We’ve seen some updates that took a few hours, and some that took a few weeks. Ultimately, it’s best to prepare yourself for the worst if you have gone many years without being conscientious about updates and upgrades along the way.

At the Very Least…

If you only take away one thing from this post, let it be this point: it doesn’t cost you money to consider your options. Talk to your developer, talk to your host, and figure out where you are at. It’s hard to understand and evaluate risk when you don’t know what your risk profile really is. You may be looking at a minor upgrade which makes sense to execute versus take the risk. Or, if you have a large amount of work done, at least use this project as an opportunity to evaluate where your business is currently positioned from a technology perspective. If an upgrade is a significant project and you were planning to rebuild in a year or two, perhaps it makes sense to wait. Either way, at the very least, figure out where you are at and what it will take to correct. Worst case scenario, if you do run into trouble later, you’ll know exactly what you need to do to maintain currency with your platform.