Dealing with the PHPocalypse

So this website is old as heck. I think some folks who are stopping by might not realize that. I launched it in 1996, and started this blog in 2001. So, y’know, thirty and twenty-five years respectively.

Because of that, this site has gone through a lot of different stuff on the backend. While it’s true that until last year a lot of it was still Perl instead of PHP, I’ve been running PHP code on parts of the site since the mid-2000s. And unlike the new scripts I wrote last year to replace the public facing Perl scripts, the old PHP files weren’t exactly up to date.

Which is why this site, until yesterday, was operating on PHP 7.4.

And that was not the worst thing in the world. Frankly, secretly I’d still been running PHP 4 until just a few years ago. I figured I’d get the site working on PHP 8 sooner or later, but I wasn’t in a rush. PHP 7.4 wasn’t a vulnerable version of the language as far as I knew.

Uh, that kind of changed this week.

Only PHP versions 8.2 and newer were getting patches, so even though my webhost installed the update to fix the vulnerability promptly, I had to get some work done to keep my site functional. I ended up doing a line by line audit of my site, digging through two decades of hacked together code, just to get the damned thing to work. It was a heck of a time.

I also had to do some work on No Brand Con‘s website too, because a plugin the organization relies on was crashing on PHP 8. Thankfully that was fixed without having to line-by-line fight the way I did with my own site, just having to re-setup a plugin from scratch to make sure the backend data was preserved. Mostly it was easy because that site is just a WordPress install, while my personal site is a homebrewed, hacked together custom CMS that no one supports but me.

So, uh, if something’s not working let me know.

It should be though.

I hope.

View Comments