PHP 5.6 to 7.2 Rabbit Hole: Part 1

Join me as I embark on a deep dive down the PHP migration rabbit hole. This will be a multi-part series as I upgrade a horrifyingly long list of legacy websites and applications from v5.6 to 7.2.

Part 1: My mess in brief.

As a freelance developer for many years, and now the owner/operator of a development company, the collection of websites and applications that I’m responsible for has grown to an impressive size. Some of these are simple, mostly-static websites with minimal use of PHP. Others are large, mature MVC applications in current use by clients. In there too is a home-grown CMS and even my own MVC framework – both of these also still in use by a few clients and projects. There are a handful of Open Source libraries and applications, plugins that I maintain for other OSS software, homepages written for family members, speculative projects that are incomplete and a few 3rd-party hosted blogs. I have a number of sites and sub-sites running on self-hosted WordPress (including this one!) and a couple of Dokuwiki sites. There is even a game or two. All in all I have:

  • 14 Client Projects
  • 24 Internal Websites & Apps
  • 9 OSS Libraries & Projects

Whew! And these are just the ones I’ve counted in a first-pass. Updating my master list in my wiki to make sure that I have these documented somewhere. Most need to be migrated to PHP 7. Along with other fixes. I also want to try to get them working locally.

  • Upgrade from PHP 5.6 to 7.2.
  • Get it working locally.
  • Ensure it is in source control (most are).
  • Enable https by default. Set up Let’s Encrypt.
  • Clean out .htaccess and php.ini files.
  • Remove any use of IonCube source encoder.
  • Update 3rd party software.
  • Preparations for PHP 8.
  • Ensure use of proper MySQL functions.
  • Proper password hashing, and replace mcrypt if used.
  • Ensure UTF8 support.
  • Check site’s error log.

Clearly I have my work cut out for me. I have actually taken a break from paying client work for a few months to tackle this head-on. The temptation of paid work having shoved this task to the bottom of my list too many times now.

I sell shared hosting and in the interest of eating my own dog-food, most of these projects are hosted with that service. They actually still support PHP 5.3 though it is marked as obsolete, 5.6 is the default, and 7.2 is available via an htaccess switch. However a major security problem with the 5.x branch could trigger them to remove it if they can’t patch it, so the clock is ticking.

To add to the load of this undertaking is the fact that until recently, it didn’t occur to me to warn my clients that they would be on the hook financially for upgrades needed to a complete and delivered website. Their hosting fees don’t cover patching or upgrading their website (which they own once delivered) but I never made this clear. Recent clients are now given the option of paying for a support-contract (automatically included with the licence fee for any software that I retain ownership of) or of paying a-la-carte for any upgrades or patches needed.

So needless to say, nearly all of this work will be done for free. I will have to find a tactful way to inform clients that this is the last time I’ll be internalizing the costs of these maintenance updates. It’s just too much to be on the hook for keeping these websites updated. As delivered projects, they no longer bring in revenue beyond minimal hosting income. Hopefully the free upgrade to PHP will ease these clients into understanding that a website, like desktop software, doesn’t exist in a vacuum and keep working forever. In business you never stop learning lessons like this.

So, this is the state of my current situation. A whole lot of legacy code that needs a ton of TLC. In the next post in this series I’ll talk about the preparation work and low-hanging fruit to tackle first.

Leave a Reply

Your email address will not be published. Required fields are marked *

three + eighteen =