PHP 5.6 to 7.2 Rabbit Hole: Part 3

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 3: Common stumbling blocks and tools to help.

To start at the beginning, Part 1 of this series has an overview of what I have to do and some of the challenges involved in a multi-site upgrade of this scale. Navigate: Previous (Part 2) or Next (Part 4)

Migrating started in earnest with one of my hosting accounts which holds a ton of my own sites and projects. As un-glamorous as it sounds, most of what I accomplished was removing old and half-done projects and ideas. I consolidated a bunch of stuff into one domain: sherriw.com and a blog there as well.

My sherriw.com site was my first opportunity to really try a migration. It ended up being so easy, that I had time to completely revamp the site and convert it to the SlimPHP framework, and switch from Mercurial to Git for this site. Awesome!

I also completed one of my very old client sites that doesn’t use a framework. Just a bunch of PHP includes. In these easy conversions, the main issues I found were:

  • PHP files with a closing ?> tag at the end. Removed.
  • The MySQL extension was replaced by the MySQLi extension. Conversion is straight forward.
  • The ereg_* functions are gone. Use preg_* instead.
  • The date function now needs a default timezone to be set. This can be done by setting it in a config or bootstrap file like so:
date_default_timezone_set('America/Toronto');

These early issues were immediately apparent simply by getting the sites working locally and just clicking through and seeing the errors. After the first few, I knew what to look for. In a future post I’ll outline even more issues I have come across.

Use Tools

Checking your sites for compatibility is even easier using some of the amazing tools available.

PHP Code Sniffer

Code Sniffer checks your code for violations based on ‘sniffs’. Sets of rules which identify code ‘smells’. Ie – bad practices and potential concerns. SitePoint has a great article on using PHPCS to check PHP version compatibility.

Once you have it installed (I did so globally), along with the PHPCompatibility sniff, you run it in the current directory. You must have the target version of php installed locally too. Run it like so:

phpcs --standard=PHPCompatibility --runtime-set testVersion 7.2- . 

It gives a report of the issues that you will encounter in the codebase for version 7.2. Basically a checklist of things to fix. Awesome!

PHP CS Fixer

Want to see potential problems AND have them automatically fixed? PHP Code Style Fixer will fix your code for you, or just show you what it found. While I’m doing all these migrations, I’m also giving my code a quick look for PSR1 & PSR2 compatibility as well as checking for short PHP open tags which will be deprecated in 7.4 then removed in 8.

Here’s how to check for the PSRs:

php-cs-fixer fix . --rules=@PSR1,@PSR2 --dry-run --verbose

And here’s how to check for short open tags:

php-cs-fixer fix . --rules=full_opening_tag --dry-run

Obviously these tools can’t catch everything. But they are an excellent way to start, especially on a large application. Or as in my case, projects that don’t have tests.

Finally, it was quite straight forward to migrate simple websites, and honestly that’s no surprise. These sites don’t do much so there was less to break. In a future post I’ll dig into upgrading a more complicated project, and provide more details about issues I’ve found.

Leave a Reply

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