When I hear the terms PHP-Selector or MultiPHP in the context of shared web hosting, this usually causes me to cringe a little bit. To be fair, there’s really nothing wrong with being able to select different PHP releases, my main gripe is with the ability to select old and outdated releases of PHP using these methods.

To better understand this, consider the lifetimes of a particular version of the PHP language. PHP, as some of you may be aware, is a web programming language. PHP is developed by the folks over at php.net and they release new versions from time to time. Typically a PHP release version (i.e. PHP version X.Y) will have a lifetime of about 3 years. During that lifetime various security releases may be released (i.e. PHP version X.Y.aa). These security releases rarely change any functionality but serve to fix security holes that have been discovered in those releases.

Why is end-of-life important? We covered that in a blog post back in October 2013. Basically, programmers and developers eventually have to end support for something so they can move on to bigger and better things. When a PHP release reaches end-of-life, that means it’s no longer being actively developed or maintained by the PHP developers – who are the ones that created it.

So this begs the question, from a pure security perspective, why should any end-of-life release of PHP be used? And that’s a very good question. The answer is that it shouldn’t be used. At the time of this blog post (September 2016), two PHP relases remain in life, PHP 5.6 and PHP 7.0 (see http://php.net/supported-versions.php). What this effectively means, is that as far as the PHP developers are concerned, PHP 5.6 and PHP 7.0 are the only releases that should be used. Yet, the web hosting industry is littered with PHP Selectors and MultiPHP systems that allow:

• PHP 5.5 (end-of-life: July 2016 – 2 months ago)
• PHP 5.4 (end-of-life: September 2016 – 1 year ago)
• PHP 5.3 (end-of-life: August 2014 – 2 years ago)
• PHP 5.2 (end-of-life: January 2011 – 5.5 years ago)
• PHP 5.1 (end-of-life: August 2006 – 10 years ago)
• PHP 5.0 (end-of-life: September 2005 – 11 years ago)

and more being made available. Why?

A common refrain I see for reasoning this is – “My script does not work on the latest release of PHP”. This is probably true, but instead of caving in and looking for a one-click easy solution of providing an outdated release of PHP, why not ask: “Is the script up-to-date and being kept up-to-date?”

We have already detailed in a previous blog post how the so-called Panama Papers were compromised due to the fact that the law firm holding the papers was using outdated versions of WordPress and Drupal on their website. So if you want to keep your website and the information behind your website safe, keeping your scripts up-to-date is one of the best thing you can do. Also worth mentioning is that a hacked or compromised script can have adverse affects for other users on a shared hosting server. If a website is hacked and compromised on a server and used to send out spam, that can have an adverse affect on other websites hosted on that shared hosting server..

So if you are using a script or CMS that does not work on current and supported releases of PHP, then that should tell you that the script or CMS you are using is out-of-date. If your script or CMS is out-of-date, it really doesn’t matter how patched up or hardened the underlying PHP release is, if your script or CMS is out-of-date, chances are great that it is vulnerable to some type of security exploit, and no amount of hardening of the underlying PHP release is going to protect you.

Being able to select old releases of PHP to allow you to continue to run your outdated script or CMS may look nice. It may allow you to keep your website up longer without any intervention on your part. But please understand, it’s just masking the problem that your script or CMS may be vulnerable to a much larger and much heavier attack. Hosting companies and administrators that suggest using these out-of-date PHP releases as a solution to your problem, either don’t understand enough, or don’t care about the security of your website or the well-being of other customers on the server and instead are just looking for an easy fix.

Steven
AMS Support

We have recently run into a few issues where users were attempting to parse PHP code in .html files. We don’t recommend this, and this post is meant to explain why.

First of all, an understanding of file extensions need to be made. Technically speaking, a file extension doesn’t really mean anything. In Windows, a file extension tends to have more meaning than in other operating systems, like Linux (which is what our servers run on). File extensions are largely hidden in new versions of Windows, but people who are familiar with older versions of Windows (and DOS) may remember that files with a .exe extension were able to be “run”. These were “executable” files that would start a program or application. Likewise a .doc file would open up the file in Microsoft Word. A .txt file would open the file up in notepad.

But technically speaking, you could just as easily open up Notepad, type up some notes, and save that file as “notes.exe”. All this would really do is confuse other users because they would expect “notes.exe” to run something and in order to open and read the file, users would have to know to open the file directly from Notepad.

In this sense, we can see that a file extension’s main purpose is used to categorize files. We have been brought up in a culture where .exe file extensions are meant to be “executable”, .txt files are meant to be simple text files that can be read by Notepad, .jpg files are image files meant to be opened by an image viewer. The extension of the file is meant to serve as a way to quickly and easily categorize what type of file this is.

You can think of this also as a filing cabinet. You may have an insurance statement that you would most likely file in the Insurance folder. A bank statement would be filed in the folder label Bank Statements. Can you put the insurance statement in the Bank Statement folder? Sure, nothing will stop you. But when you go to look for that Insurance statement 2 years later, where are you going to looK? In the Insurance folder or the Bank Statement folder? A statement that is misfiled can lead to a lot of headaches later down the road.

The same is true for the web experience. When working in website development there is some expectations when categorizing files. Files with a .jpg extension are expected to be image files. Files with a .css extension are meant to contain Cascading Style Sheets code. Files with .js extensions are expected to contain Javascript code. Files with .html or .htm extensions are meant to contain raw HTML code. Files with .php extensions are mean to contain PHP code. That is the expected behavior of these extensions. Can you put HTML code in a file and use a .jpg extension? Sure, but this is going to severely confuse your browser and probably won’t render correctly for your website visitors.

The same is also true about putting PHP code in .html or .htm files. This just isn’t the expected behavior. PHP code has to interface with the back-end webserver. How this is done gets technical very quickly, but just know that the web server has to talk to a system on the server that understands PHP code and interprets this back to something the web server can understand. By default the web server only sends code from .php files to this system to be interpreted. While it is true that the server can be made to send .html or .htm files, it is just not the default behavior. So any change in the way PHP operates or any change to this webserver -> PHP interface system, non-standard setups (like PHP code in .html files) may get overlooked.

The TL;DR version of this is to always be sure to use file extension properly. This is going to save you a lot of headaches later on, if you follow the expected behavior for any file extension. If you want to use PHP code, you should always use a .php file extension for that file. If you choose to operate outside of this expected standard behavior, do not be surprised when you encounter rendering issues.

Matt
AMS Support

Over the next few weeks we will be performing some updates to Apache and PHP on all of our servers. These updates are necessary to bring our servers in-line with upcoming PHP updates (PHP 7.0 and PHP 7.1). These updates should incur just a few seconds of downtime while services are restarted during the update process.

If you experience any issues after these updates, please open a support ticket so we can investigate and correct any issues.

Again, these updates are necessary so that we can deploy future versions of PHP on our servers. We don’t have an exact timetable for when each server will be updated, but our hope is to conclude all of these updates by the end of September.

Steven
AMS Support

PHP released version 5.5.38 recently for their 5.5 branch. This effectively marks the end-of-life for PHP 5.5. Although they do leave the door open ever so slightly for future PHP 5.5 releases:

Note that according to our release schedule, PHP 5.5.38 is the last release of the PHP 5.5 branch. There may be additional release if we discover important security issues that warrant it, otherwise this release will be the final one in the PHP 5.5 branch.

What does this mean for us? Not a whole lot actually. We essentially skipped over PHP 5.5 as a default version and went straight from PHP 5.4 to PHP 5.6 as the default versions on our servers. This means that very few of our accounts are actually using PHP 5.5. For those that are using PHP 5.5 we aren’t going to change you immediately to PHP 5.6. Typically we try to offer a PHP version for a year after it’s last release, meaning that we would continue to offer PHP 5.5 through July 2017. I have not looked specifically at the numbers, but there are just very, very few of our accounts that using PHP 5.5. We’re probably not going to install PHP 5.5 on any server that doesn’t already have it. But if you are using PHP 5.5 you are safe likely for another year (an unpatched security hole in PHP 5.5 may change our timetable). But if you are using PHP 5.5, now would be a good time to start thinking about upgrading your scripts and systems to ones that support PHP 5.6 or perhaps higher.

This brings us to our current PHP offerings and schedule. Currently PHP is supporting PHP version 5.6 and PHP version 7.0. PHP 7.1 is in beta and may get a public release in the not to distant future. PHP 5.6 won’t go end-of-life until December 31, 2018. PHP 7.0 won’t go end-of-life until December 3, 2018. We aren’t currently offering PHP 7.0, mainly because Ioncube and Zend do not yet have encoder support for PHP 7. Adding PHP 7.0 support is on our list of server todos.

Because of the success we had with skipping PHP 5.5 as a default version, we are considering doing the same thing with PHP 7.0. PHP 5.6 still has a lifetime of over 2 years remaining. PHP 7.1 will probably be here before the end of 2016. It really just depends on how things go, but it’s looking like we will skip PHP 7.0 as a default version and go straight to PHP 7.1 as the default version successor to PHP 5.6. Like PHP 5.5 we will offer PHP 7.0, just not as a default version. When will we make a default PHP change? Not before Ioncube and Zend release loaders for PHP 7 or PHP 7.1.

None of this is really written in stone at this point, but this is our current line of thinking. It really depends on how adoption of PHP 7.0 and PHP 7.1 goes from the standpoint of script developers. Right now, adoption of PHP 7.0 is slow – again this may be because of the lack of Ioncube and Zendguard support. It may be that adoption of PHP 7.0 and PHP 7.1 remains low, allowing us to extend PHP 5.6 even longer until PHP 7.2 comes out. All of that just remains to be seen. But it is looking like we are going to skip PHP 7.0 as a default version.

Steven
AMS Support

At AMS Computer Services we always focus on customers first. And in that sense, we are always looking for ways we can better serve our customers. Are there things we could be doing better? Are there services or features that our customers would like to see added? What are the things we are doing well?

All of this requires communication and feedback from our customers. That’s why we have released our Customer Survey to get a better idea of what is important to you – the customer – and what we can do to serve you better.

We invite you to complete the Customer Survey. It is a very short survey and is completely anonymous. We just want to know what we can do to make sure your hosting experience at AMS Computer Services is the best it can be.

AMS Computer Services – Customer Survey

John
AMS Sales