Category: Software Upgrades

We were recently working on doing an upgrade of some very out-of-date software. As part of dealing with that, there was a need to change the PHP version being used on the website. We needed to change to a version that the web host of the website, HostGator, doesn’t appear to provide the ability to change to. The client thought that you had to go through HostGator’s support to change it to that version. It certainly looks like that, as they have a selector for customers that only allowed you to change to version to 8.1, 8.2, or 8.3:

Going through hosting support to address something that would be inconvenient at best. There is a simpler way to handle this. In root directory of the files for the website we were dealing with, was a .htaccess file. In that, there were the following lines:

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php56” package as the default “PHP” programming language.

  AddHandler application/x-httpd-ea-php56___lsphp .php .php5 .phtml

# php -- END cPanel-generated handler, do not edit

That code specifies what version of PHP is used on the website. The version of PHP being used on the website was 5.6. If you look closely at that, you can see at one point it says “php56”. Changing that changes the PHP version. So, for example, changing it “php74” would change the version of PHP being used on the website to 7.4.

While the first line says to not edit this, you can safely change the version there.

Another useful feature of changing the PHP version that way is that you can set the PHP version to a different version for different directories on the website. So we could in this change the version of a directory containing a test of the upgrade without impacting the running website.

We often find that businesses’ investment in terms of money and effort in their websites is out of line with what would be optimal. For example, you have people that spend over a thousand dollars a year on a security service that doesn’t even really attempt to secure the website, while more basic maintenance is often neglected or done by those that don’t have the necessary experience to handle it properly, even when the business has the means necessary for to avoid that and the website is critical for the business.

We recently had someone contact us looking for emergency support after a Drupal upgrade went wrong that lead to a website that they said was critical to the business not working. One way to handle that situation would be to revert to a backup, but they said the most recent backup was three months old.

If a website is critical to business then frequent backups should be made outside of any done before upgrades, so there should have been a more recent backup than that, but what about properly preparing for an upgrade outside of that? At the very least, a backup should be made before upgrade is started. If the website is critical to business though that probably isn’t enough.

One reason for that is that there is always a possibility that there is some issue that would make restoring a backup a difficult or impossible. Let’s say for some reason the backup method being used isn’t actually fully backing things up (which can happen). Someone that knows what they are doing can usually ensure that the backup is complete without having to do a test run of a restoration, but one way to test a restoration also provides a better method for handling potential issues for an upgrade.

If a website is truly critical to a business then the best thing to do is to do a test of the upgrade before the production website is upgraded. That will significantly lessen the chance of something going wrong when the production website is upgraded, which would then require trying to quickly fix it or revert to a backup. Instead time can be takem to understand what is going wrong and how to ameliorate that before the time comes to upgrade the production website. Setting up the test copy of the website also allows testing out the restoration of a backup as well.

Usually a test copy of the website can simply be set up in a directory in the existing website’s hosting account/domain name. A more advanced way to handle it is to use a separate hosting environment, say a separate hosting account, though with that it is important to make sure the server environment is the same as the production website, so that some inconsistency between them doesn’t lead to an issue only appearing when the production website is upgraded.

Finally, testing out the test of the upgrade. For some types of website a quick check over few pages will be enough but in others more extensive manual or automated testing may be needed. Another sometimes overlooked area of testing is becoming familiar with functionality changes in the backend of websites when significant upgrades are made. We have been involved in situations where that hasn’t happened and someone then was panicking because they needed to do something in hurry, but weren’t aware of how to do that it in the new version, so trying out normal activities in the test copy we a significant upgrade is being done is very good idea.