Which are the PHP 8.0 Significant Incompatibilities to expect?

PHP 8.0 is around the corner, with major applications starting their move to have compatible code by early December 2020. This is the case of WordPress, Laravel, or PHP-CS-Fixer. Exakat is all ready, both for running on PHP 8.0, and auditing PHP 8 code.

What about the code of the rest of us? Which are the most common problems that will pounce when the time to jump version is arrived? We took upon us to peek at the future and help the PHP community get ready.

To identify the upcoming problems, we used the 13 Migrations to PHP 8.0 rules that are already supported in Exakat, and ran it over 1700 Open Source applications. Each project, small or large, is counted once, whenever the rules detect at least one issue in the code.

This gives us the following results :

• Negative Start Index In Array : 0%
• PHP 8.0 Removes Resources : 0%
• Nullable With Constant : 0.7%
• Cast Unset Usage : 1.0%
• $php_errormsg Usage : 2.3%
• PHP 8.0 Removed Constants : 4.7%
• PHP 80 Named Parameter Variadic : 5.2%
• Concat And Additions : 7.3%
• PHP 8.0 Removed Directives : 7.3%
• Old Style Constructor : 14.7%
• PHP 8.0 Removed Functions : 25.3%
• Mismatch Parameter Name : 49.5%
• Unsupported Types With Operators : 61.0%

Some remarks

• The move away from resources and toward objects (for example, curl_init() will return an object, not a resource anymore) didn’t return anything. It seems like no code would check the results of curl_init() (and co) with \is_resource(). The common practice is to use a simple if (!$curl). Yet, such a low result is surprising, we need to investigate more.
• PHP 4 constructors are still in lots of sources : one project over seven. Most of the time, they are PDF, Tar or Zip libraries, that have been ported since PHP 4. Some serious refactoring will happen there.
• Changing parameter names between methods in different inherited classes is (sadly) a very common practice. This will be an issue with named parameters, as multiple names will be solved down to one by PHP. Though, it will not happen until the named parameters are used. Until then, it is recommended synchronizing all those names.
• Unsupported Types, used with various operators, is quite wide spread. With the PHP 8.0, the old way of silent cast to null, is upgraded to the visible TypeError exception : logs will fill fast. Given the dynamic nature of those events, it is reasonable to run the code with PHP 8.0 as soon as possible.

Check Your Code With Migration PHP 8.0 report

Exakat provides a special report : Migration PHP 8.0. It provides 13 analysis to prepare your code to PHP 8.0.

To get the report, you need Exakat, then the following commands :

php exakat.phar init -p myproject -R <project_URL>
php exakat.phar project -p myproject
php exakat.phar report -p myproject --format Migration80 

At that point, the report is now in the projects/myproject/migration80/ folder. You may open the index.html in that folder to open it in your browsers.

You may also use the Text version :

php exakat.phar report -p myproject --format Text -T CompatibilityPHP80

This one will report the same information, directly in the standard output.

We are always listening for backward incompatibility that should be tracked and reported. Drop us a note @exakat on twitter, or in the group.

Happy auditing

Moving to PHP 8.0 will be an easy migration, with backward incompatiblities affecting mostly rare code. There is a wealth of new feature available, on top of speed improvements and security.