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.3.

Part 4: PHP Version 7.3 arrives!

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 3).

While slogging through this migration project, PHP version 7.3 arrived on my servers. Eeek! As I’m only about 20% of the way through migrating my projects, it only made sense to go back to the projects I’d already done and migrate them to 7.3. So… as you can see from the title of this post, and future ones, it will now be about migrating 5.6 to 7.3.

The main things that tripped me up going from 7.2 to 7.3 were some heredoc string parsing issues, and mixed line endings. Other than that, phpcs and php-cs-fixer are mostly flagging issues with visibility (public/private) on my class attributes and methods. Easy fix. Luckily I had been checking for Full Opening PHP Tags all along so most of those were already fixed.

My new code sniffer tests I’m using for phpcs and php-cs-fixer to check each project’s source before testing it in use, are:

phpcs --standard=PHPCompatibility --extensions=php,inc,lib --runtime-set testVersion 7.3- . 


php-cs-fixer fix . --rules=full_opening_tag,@PSR1,@PHP70Migration,@PHP71Migration,@PHP73Migration --verbose --dry-run --using-cache=no

On a side note… having automated tests for projects would have made this a much easier and more confident process. Alas, I have not applied TDD for old projects and have almost no PHPUnit tests for anything other than my most recent project. So… manual testing it is.