{"id":69661,"date":"2022-12-21T09:01:56","date_gmt":"2022-12-21T09:01:56","guid":{"rendered":"https:\/\/www.cryptocabaret.com\/?p=69661"},"modified":"2022-12-21T09:01:56","modified_gmt":"2022-12-21T09:01:56","slug":"how-to-migrate-your-code-from-php-7-4-to-8-1","status":"publish","type":"post","link":"https:\/\/www.cryptocabaret.com\/?p=69661","title":{"rendered":"How to migrate your code from PHP 7.4 to 8.1"},"content":{"rendered":"

How to migrate your code from PHP 7.4 to 8.1<\/span>
\ngilzow<\/a><\/span>
\nWed, 12\/21\/2022 – 03:00<\/span><\/p>\n

\n

The end-of-life (EOL) for PHP 7.4<\/a> was Monday, November 28, 2022. If you\u2019re like me, that date snuck up much faster than anticipated. While your PHP 7.4 code isn\u2019t going to immediately stop working, you do need to begin making plans for the future of this codebase.<\/p>\n

What are your options?<\/h2>\n

You could continue to remain on PHP 7.4, but there are several benefits to updating. The biggest are security\u00a0risk and support. As we move farther and farther away from the EOL date, attackers will turn their focus to PHP 7.4 knowing that any vulnerabilities they discover will go unpatched in the majority of systems. Staying on PHP 7.4 drastically increases the risk of your site being compromised in the future. In a similar vein, finding support for issues you encounter with PHP 7.4 will become increasingly more difficult. In addition, you will most likely begin to encounter compatibility issues with third-party code\/packages as they update their code to be compatible with later versions and drop support for 7.4. You\u2019ll also be missing out on significant speed and performance improvements introduced in 8.0<\/a> and further improved in 8.1<\/a>. But upgrading all that legacy code is daunting!<\/p>\n

Where to start?<\/h2>\n

Luckily, PHP provides an official migration guide<\/a> from PHP 7.4 to 8.0 to get you started (and an 8.0 to 8.1 migration guide<\/a> as well). Be sure to read through the Backward Incompatible Changes and Deprecated Features sections. While these guides are incredibly handy, you may very well have tens of thousands of lines of code to check, some of which you may have inherited. Luckily there are some options to help pinpoint potential problem areas in the migration.<\/p>\n

PHPCodeSniffer + PHPCompatibility sniffs<\/h3>\n

PHPCodeSniffer<\/a> (PCS) is a package for syntax checking of PHP Code. It checks your code against a collection of defined rules (aka \u201csniffs\u201d) referred to as \u201cstandards\u201d. PHPCodeSniffer ships with a collection of standards you can use including PEAR, PSR1, PSR2, PSR12, Squiz, and Zend. Luckily, you can write your own collection of sniffs to define any set of rules you like.<\/p>\n

\n

PHPCompability has entered the chat<\/p>\n<\/blockquote>\n

PHPCompatibility<\/a> \u201cis a set of sniffs for PHP CodeSniffer that checks for PHP cross-version compatibility\u201d allowing you to test your codebase for compatibility with different versions of PHP, including PHP 8.0 and 8.1. This means you can use PHPCodeSniffer to scan your codebase, applying the rules from PHPCompability to sniff out any incompatibilities with PHP 8.1 that might be present.<\/p>\n

Before I continue\u2026<\/h2>\n

While PHP8.2 was released on December 8, 2022<\/a>, and I encourage you to begin looking over the official 8.1 to 8.2 migration guide<\/a> and begin making plans to upgrade, most of the checkers I mention in this article have not completed full support for 8.2 at this time. For those reasons, I\u2019ll be focusing on migrating the code to PHP8.1, and not 8.2.<\/p>\n

In the process of writing this article, I discovered PHPCompatiblity has a known issue<\/a> when checking for compatibility with PHP 8.0\/8.1 where it will report issues that should be Errors<\/strong> as Warnings<\/strong>. The only workaround for now is to use the develop<\/code> branch for PHPCompatibility instead of master<\/code>. While they state it is stable, please be aware that in this article, I\u2019m using the non-stable branch. You may want to weigh the pros and cons of using the develop<\/code> branch before implementing it anywhere else than in a local development environment. While I found PCS+PHPCompatibility to be the most straightforward and comprehensive solution for checking for incompatible code, if you do not want to use a non-stable version of PCS, see the section at the end of the article about alternative options.<\/p>\n

For the purposes of this article, I\u2019ll be using the 1.4.6 version of SimpleSAMLphp<\/a> to test for incompatibilities. This is a six-year-old version of the code base. I do this not to pick on SimpleSAMLphp, but because I wanted something that would definitely<\/em> have some errors. As it turns out, all of the platform.sh code I tested, as well as my own code was already compatible with PHP8.1 and required no changes.<\/p>\n

Get started<\/h2>\n

To get started, first clone your codebase, and then create a new branch. You\u2019ll now need to decide if you want to install the dependencies and run the scans on your local machine or in a local development environment using something like DDEV<\/a>, Lando<\/a>, or\u00a0Docksal<\/a>. In this demo, I\u2019m using DDEV. I suggest using a local development environment vs running directly on your local machine because while it\u2019s not required to use the version of PHP you want to test against, for the best results, it is recommended you do so. If you don\u2019t have PHP installed, or don\u2019t have the target version installed, a local development environment allows you to create an ephemeral environment with exactly what you need without changing your machine.<\/p>\n

After setting up your environment for PHP 8.1, at a terminal prompt (in my case, I\u2019ve run ddev start<\/code> and once the containers are available, shell into the web app using ddev ssh<\/code>), you need to add these new packages so you use them to test with. I\u2019ll be adding them with composer, however, there are multiple<\/a> ways<\/a> to install<\/a> them<\/a> if you would prefer to do so differently. If your codebase isn\u2019t already using composer, you\u2019ll need to do composer init<\/a> before continuing.<\/p>\n

Because you’ll be using the develop branch of PHPCompatibility there are a couple of extra steps to do that aren\u2019t in the regular installation instructions. First is that the develop branch of PHPCompatibility requires an alpha version of phpcsstandards\/phpcsutils<\/code>. Because it is marked as alpha, you’ll need to let composer know this one package is OK to install even though it is below your minimum stability requirements.<\/p>\n

$ composer require --dev phpcsstandards\/phpcsutils:\"^1.0@dev\"<\/code><\/p>\n

Next, install PHPCompatibility targeting the develop<\/code> branch<\/p>\n

$ composer require --dev phpcompatibility\/php-compatibility:dev-develop<\/code><\/p>\n

The develop<\/code> branch also installs dealerdirect\/phpcodesniffer-composer-installer<\/code> so you don\u2019t need to add it manually or direct PCS to this new standard.<\/p>\n

To verify our new standards are installed, you’ll have PCS display the standards it is aware of.<\/p>\n

\n$ phpcs -i\nThe installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz, Zend, PHPCompatibility, PHPCS23Utils and PHPCSUtils<\/code><\/pre>\n
Now that you know your standards are available, you can have PCS scan our code. To instruct PCS to use a specific standard, use the --standard<\/code> option and tell it to use PHPCompatibility<\/code>. However, you also need to tell PHPCompatibility which PHP version you want to test against. For that, use PCS\u2019 --runtime-set<\/code> option and pass it the key testVersion<\/code> and value of 8.1<\/code>.<\/p>\n
Before you start the scan, the one issue remaining is that code you want to scan is in the root of the project (.<\/code>) but the vendor<\/code> directly is also in the project root. You don\u2019t want the code in vendor<\/code> scanned, as those aren\u2019t packages you necessarily control. PCS allows you to tell it to not scan files\/directories with the --ignore<\/code> option. Finally, you want to see the progress as PCS parses the file so you’ll pass in the -p<\/code> option.<\/p>\n
Putting it all together:<\/p>\n
$ phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.1 --ignore=*\/vendor\/*<\/code><\/p>\n
This kicks off PCS which will output its progress as it scans through your project\u2019s code. W<\/code> indicates Warnings<\/strong>, and E<\/code> indicates Errors<\/strong>. At the end of the scan it will output: a full report with the file containing the issue, the line number where the issue occurs, whether the issue is a Warning<\/strong> or an Error<\/strong>, and the specific issue discovered.<\/p>\n
In general, Errors<\/strong> are things that will cause a fatal error in PHP 8.1 and will need to be fixed before you can migrate. Warnings<\/strong> can be things that have been deprecated in 8.0\/8.1 but not yet removed or issues that PCS ran into while trying to parse the file.<\/p>\n
\"asciicast\"<\/a><\/p>\n
Given that the report might be long, and is output all at once into your terminal, there are numerous options<\/a> for changing the information that is included in the report, as well as multiple reporting formats.<\/p>\n
As you begin to fix your code, you can rerun the report as many times as needed. However, at some point, you\u2019ll need to test the code on an actual PHP8.1 environment with real data. If you\u2019re using Platform.sh<\/a>, which is as easy as creating a branch, changing a single line in your configuration file, and pushing that branch to us. You can check out this video<\/a> to see how easy it is!<\/p>\n
There\u2019s too much to fix!<\/h2>\n
Now that you have a solid idea of what needs to be updated before you can migrate, you might be facing an incredible amount of work ahead of you. Luckily, you have some options to help you out. PCS ships with a code fixer called PHP Code Beautifier and Fixer<\/a> (phpcbf<\/code>). Running phpcbf is almost identical to running phpcs and most of the options are identical. The other option is Rector<\/a>. Usage of these tools is beyond the scope of this article, but as with any automation, you\u2019ll want to test and verify before promoting changes to production.<\/p>\n<\/p>\n
\n
Programming and development<\/div>\n
\n
Red Hat Developers Blog<\/a><\/div>\n
Programming cheat sheets<\/a><\/div>\n
Try for free: Red Hat Learning Subscription<\/a><\/div>\n
eBook: An introduction to programming with Bash<\/a><\/div>\n
Bash shell scripting cheat sheet<\/a><\/div>\n
eBook: Modernizing Enterprise Java<\/a><\/div>\n
An open source developer’s guide to building applications<\/a><\/div>\n<\/p><\/div>\n<\/p><\/div>\n
Alternative options<\/h2>\n
If for any reason you don\u2019t feel comfortable using a non-stable version of PCS, you do have other options for checking your code.<\/p>\n
Phan<\/a><\/h3>\n
Phan is a static code analyzer for PHP. It offers multiple levels of analysis and allows for incrementally strengthening that analysis.<\/p>\n
\u201cStatic analysis needs to be introduced slowly if you want to avoid your team losing their minds.\u201d<\/p>\n
Phan doesn\u2019t target just compatibility with newer versions, it can highlight areas of code that will error in later versions. However, there are some caveats when using Phan for checking compatibility:<\/p>\n