Category: Software Upgrades

You Might Need to Upgrade MediaWiki in Steps Even if the Manual Says Otherwise

It used to be that you could upgrade an older version of the MediaWiki software directly to the latest version. According to the manual for that, that officially changed as of version 1.36:

Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago (see phab:T259771). Upgrades from older versions of MediaWiki will have to be performed in multiple steps. This means that if you want to upgrade to 1.36 from 1.23 or earlier, you’ll first have to upgrade your 1.23 wiki to 1.27 (or 1.35), and, from 1.27 (or 1.35), you’ll be able to upgrade to 1.36.

We were brought in to do a MediaWiki upgrade for a website running version 1.31 recently. According to that information, that should have been upgradeable directly to the latest version, 1.39, as 1.31 and 1.35 are the two long-term support (LTS) versions before 1.39. Instead, when doing a direct upgrade, we found the website was broken. We also found that doing an intermediate upgrade to 1.35 before going to 1.39 produced the same result. What we found from further testing is that it needed to be upgraded to 1.33 before being upgraded to 1.39 to avoid the website being broken after the upgrade.

One way to avoid problems here would be to do an upgrade to each major version instead of skipping any. That approach isn’t necessarily very practical depending on the amount of time it takes to do each upgrade, which can be considerable depending on the particulars of the website and the server it is on.

Another way to avoid problems is to make sure to do a test of the upgrade first. That way you don’t find that the website is broken after the upgrade and you are trying to rush to fix the problem. As we were doing a test first, we could patiently look into the problem and found the easiest way to resolve it was to do that intermediate upgrade.

Upgrading Semantic MediaWiki When You Don’t Have Access to the Command Line (Shell)

The tools and access that those developing web software have available is not always the same as those available to those running the software on their website. Case in point, we were recently working on an upgrade of a MediaWiki website using the Semantic MediaWiki extension where there wasn’t access to the command line (shell) with the hosting account for the website. The upgrade process for Semantic MediaWiki involves you having that access. We were able to work around that and we have some important information for anyone trying to do that as well.

What we thought we could do is to prepare the files for the upgrade on a local copy of the website, copy those to the server, and then do the database upgrade on the server. That didn’t work out.

Upgrading the files needs to be done elsewhere than the website since it relies on Composer. We thought that we could run the database update for Semantic MediaWiki on the server though, since MediaWiki has a web updater for those not able to run its updates through the command line. While that worked for updating MediaWiki on this server, we found that the Semantic MediaWiki upgrade didn’t get applied when doing that.

After doing the database update elsewhere and copying that to the server, we ran into another problem. We got this error message:

Semantic MediaWiki was installed and enabled but is missing an appropriate upgrade key.

With the code “ERROR_SCHEMA_INVALID_KEY“.

The linked documentation wasn’t all that helpful on what was at issue there. What we found was that a change needed to be made to the file /extensions/SemanticMediaWiki/.smw.json. Specifically, the database name in that file needed to be corrected to match the name of the database on the server. The contents of the file look like this:

{
“databasename”: {
“upgrade_key”: “b1d9d6bec582041a8aca10a4d380cfc75aa86e7f”,
“maintenance_mode”: false
}
}

In a real file, instead of databasename would be the name of the database. Correcting that resolved the error.

Features of Your Website Will Not Stop Working if You Don’t Switch to PHP 8 By November 28

We recently got the following frightening sounding spam email, with the subject “PHP Version Upgrade”, claiming that features of websites will stop working on November 28 if PHP isn’t upgraded to version 8:

I hope everything is going perfect at your end. I am writing this email on the behalf of my IT company having specialization in different technologies and platforms. This email is in the context of outdated PHP version of our website. Your website is running on PHP version below 8.0 which is going to be totally outdated on 28th November 2022. You need to get the website updated immediately else some features will stop working after that.

We can assist you with this easily. Please let me know if you want to upgrade the website to PHP version 8.0 or higher and we will be sharing our quotation for the same accordingly.

That isn’t true.

What this relates to that is real is that the last version of PHP below 8, 7.4, will lose official security support from the developers on that day. Earlier versions, though, will continue to work after that, as has always been the case. So nothing will stop working on websites still using an earlier version of PHP.

Running a version of PHP that doesn’t have security support from the developers doesn’t mean that your website is at risk of being hacked, either. For that to be the case, there would need to be a serious vulnerability found and no unofficial update for it made available or that update isn’t applied to PHP on the server. There hasn’t been a vulnerability in PHP that has led to widespread hacking of websites in many years. It also isn’t uncommon for websites running a supported version of PHP to not be running the latest version of it.

What Changing to PHP 8 Involves

If you do want to change to PHP 8, it possibly involves two separate sets of actions. One of which can actually cause features of the website or the entire website to not work. The action that could cause that is changing the version of PHP in use to version 8. The reason for that is that not all older software is designed to be compatible with PHP 8.

How you change the PHP version in use to 8 depends on your hosting set up. In some cases, it is as simple as changing a setting in the hosting control panel associated with the website. In other cases, it could involve the website’s web host needing to move the website to a new server.

The other action that might need to be done is to change the software on the website to be compatible with PHP 8, so that features of the website or the whole website doesn’t stop working. That might be handled by updating software on the website. Or it might involve rewriting code if custom code is used or if third-party code used hasn’t already been updated for PHP 8.

Should You Be Making This Change?

While it is a good idea to keep your website up to date and running supported software for security purposes, it is important to understand that running outdated software doesn’t automatically put your website at risk. It is even possible that a new version of software introduces a vulnerability that didn’t exist before.

Your best option is to have a relationship with a company or individual that can give you honest advice on how you can best keep your software up to date within your budget and what might be the pitfalls of changing between major PHP versions, like a switch from PHP 7 to 8, with the software on your website, so those can be dealt with in a way that lessens possible problems.

We handle upgrades of a variety of popular web software and have many years of experience dealing with changes that need to be made to avoid incompatibilities with new versions of PHP.

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.