Reading Time: 7 minutes
I run a bunch of web apps. It’s usually pretty easy. Each app updates as new features or fixes roll out. They all run on PHP and I have worked with them for a couple of years or more each. After an update, I can usually get in and fix things that aren’t working. But recently, I realized that the version of PHP I was relying on – 7.4 – had reached end of life and the longer I delayed updating it, the more the risk would grow of being hacked.
This may seem like a small thing but it’s the one hard and fast rule I think I have when it comes to web apps. Don’t make the internet worse – don’t be part of the problem. I ran an email server for a long time, on my own hardware. It was simple and it gave me a lot of opportunity to fiddle around with mail software. But email servers are used to relay messages and, if you don’t secure it properly and keep it patched, it will relay messages other than yours. As the complexity ratcheted up, the value to me of being able to tinker was outweighed by the increasing likelihood I would make things worse.
I was more confident with my ability to host my own web site. In the case of my web site, it tended to be my inability to ensure the web server wouldn’t randomly crash and become unavailable. Hardware? Software? Either way, in conjunction with the email server, I ended up going to hosted web support. If you use a host like I do – Siteground or A2Hosting – you end up with a web server, email server, and plenty of tools to manage your technology. There are more tech-focused hosting options, where you can choose everything, including an operating system, that you’ll run. For me, it was enough to have them take care of all of the underpinning technology: web server software, supporting language, etc.
Web hosting is just a matter of cost shifting. If I run my own hardware, I need time to learn and implement, adequate internet, electricity, software licenses. If I use a web host, I pay them for some of that. If I use a web consultant, I pay them for other parts (especially time and implementation) of the resources required.
End of Life
I do not normally like to be on a product at its end of life. In the case of Windows, I tend to be well ahead of the versions of Windows approaching end of life (EOL). My folks were happily running Windows 7 up until a few years, when I upgraded them to Windows 10. They are, like many consumers, accustomed to using what they own. When I worked at the ABA, we had one lawyer who notoriously was using Windows 98 well after support ended in 2002. In our family, I try to ensure we’re on the current OS number (currently Windows 11) and then I run my own machine on a preview edition.
An upgrade to a Windows operating system is pretty straightforward. You can usually just run the new system upgrade right over the old one. It replaces it, but many things just keep working. I can’t remember the last Windows app I had that didn’t keep working after an upgrade.
If you’re not sure what your (or anyone’s) site is running, you can do some investigation with sites like Netcraft and Builtwith. For real detail, though, you may need to dig on the actual server. If you can’t see the information on the CPanel for the site, you may need / want to create a simple PHP file that will show you the information about your PHP environment.
An upgrade to PHP can be a bit more difficult. First, I should say, I wasn’t going to be touching the PHP software itself. I have found, with the web hosts that I use, that they have multiple versions of PHP installed in parallel. That way, you can just use the one you need for your apps. PHP 7.4 is past end of life and security support lasted until November 2022. Version 8.0 will lose security support at years end. Version 8.2 is the current version that has the longest current shelf life.
In a hosted environment, changing versions is as easy as opening a dropdown list and picking the one you want. When you select a new version, the available modules will change to reflect what is available on your web host. If you need additional ones, you can add them. If you add something that relies on a second module or that creates a conflict, this CPanel PHP selector will warn you.
It’s disarmingly simple. In theory, you could just select a new version and your web site and other apps will just keep running. It’s a potentially risky approach, though. As I found, as I started to dig into my upgrade.
The Valley of Requirements
The ideal world involves a testing environment. You can make your upgrades and changes and see what works or breaks. But no one else will see your efforts until you’re ready to make them public, when everything works. In IT terms, you want at least a staging server and, potentially, a development server.
Most web hosting companies will offer a staging environment. If I was attempting any of this at my law library or workplace, I’d use one. I wasn’t sure I wanted the additional work of a staging environment for my personal site. I had a backup in case of catastrophe. But there was never a risk of catastrophe.
The first thing I did was to check to see what versions of PHP I could use with my apps: WordPress, Piwigo, FreshRSS, and Matomo. Most will have a requirements page (WordPress, Piwigo, FreshRSS, Matomo) to help you wrangle your target. Not always, though. They may only specify a “not older than” and those versions may be quite old. And you may have reasons to run on older versions, I’m not judging. But the requirements are usually minimums and may not reflect their compatibility with newer versions.
In my case, I found that Piwigo was not compatible with PHP 8.2. The developers explained that, based on their platform, they were not keeping up with the latest PHP versions. So now I was going to aim for something other than 8.2. The next obvious choice was 8.1.
Since I know when most of my traffic comes to my site – and most of it is only on WordPress, since the other tools are just really for me – I made a window to just flip over to 8.1 and see what broke. In this case, “break” would mean not responding. No files or data was changed. It was just “can the app understand how to start” under the newer version.
Everything was fine. Everything, that is, except WordPress. That was a surprise. Because I knew it was compatible with both 8.1 and 8.2. (Not shown on Make WordPress’s Core handbook compatibility page, unfortunately, which hasn’t been updated in a few years) I flipped it back to 7.4 for the moment.
Bug Hunting, Rule Following
I went into the WordPress configuration file and turned on debugging. This is pretty easy. And another benefit of this sort of web hosting. Most of what I need to do I can do through user interfaces. But everything else I can do through file edits and a file transfer protocol (FTP) app. Even when WordPress won’t let you log in because of a software change you make, you can bypass that to get back into your site so long as you have FTP access.
Now I flipped PHP back to 8.1 and loaded my WordPress page in a browser. Now I could see the errors. I flipped it back to PHP 7.4 and went and hunted down the bug.
This is the moment when I was glad that I follow whatever WordPress best practices I know of. One choice I make on all of the sites I run is to use a free Automattic theme. They provide lots of functionality and variety and I know that Automattic, WordPress’ owner, will update them.
Like most people, though, I want my theme to be a little bit different. So I use the child theme approach recommended by WordPress. It’s incredibly easy and it means that your customizations are separate from the original theme. It means the original theme can be updated for security and other reasons. And your customizations will sit on top of the updated theme, without losing them on each update.
In my case, the reason that I was having compatibility issues was because WordPress was compatible but one edit I’d added to my child theme wasn’t. I was able to remove it from the functions.php file and flip back on PHP 8.1. Everything worked as normal.
I don’t mean to suggest that upgrading in this way is the best approach or even that it is always this easy. In the end, it confirmed my feeling that a staging environment was not necessary. I hew pretty close to staying between the lines and didn’t expect to find anything too difficult to fix. If I was an actual developer, and had done more customization, that might have been a different situation.
Like everything else in web design and presentation, it’s cost shifting. If I create a true staging server, it needs to be identical to my production server. When I worked at the American Bar Association, they experienced huge cost over runs because they had development and staging servers that did not match their many production servers and so not only did they have the cost of maintaining software licenses on all of these servers, they didn’t even have the ability to replicate staging success on production servers. It was a nightmare. I would rather keep my innovation within some bounds to avoid having to create additional technical complexity (or pay someone to manage that complexity for me).