Make Sure to Upgrade Zen Cart Before Your Web Host Changes the PHP Versions They Support

We recently have had a significant number of people coming to us for Zen Cart upgrades needed due to web hosts changing the minimum PHP version they support. Unfortunately a lot them have been at the point that the website is broken due to that PHP change happening, so now would be good time to assess whether you are in need of an upgrade before you run in to problems.

The lowest version of PHP still supported is 7.1 and version 1.5.5 of Zen Cart and above are designed to support that. Support for PHP 7.1 will end on December 1.

If you upgrade to the latest version of Zen Cart, 1.5.6, you have years of support built in as that is designed for PHP versions up to PHP 7.3, which is supported until December of 2021.

While the lowest supported version of PHP is currently 7.1, one of the recent situations where we were brought in involved the web host raising the minimum PHP version to 5.6, which Zen Cart 1.5.3 and above were designed for.

Making the upgrade process more difficult in some instances is that one change made with Zen Cart 1.5.6 is that it will not run with versions of PHP lower than 5.5 (previous Zen Cart versions would run on older versions of PHP enough to test things out before switching to a newer version).

If Your Website Is Critical to Your Business Make Sure You Properly Prepare for Software Upgrades

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.