Le 15/02/2022 à 13:46, Thomas Nunninger a écrit :
Hi Nicolas,
as far as I understand, adding new ini settings is not the way to go
as this would mean that your code behaves differently on different
environments.
Two suggestions:
* Write your own error handler that ignores those errors.
* Try some tool like Rector to rewrite your code.
Best regards
Thomas
Hello,
I do agree with Thomas here, changing PHP internal behavior by
configuration is a dangerous thing to do.
If I understand correctly, there is "more than 130 000 lines of PHP
code" to fix, believe me I migrated a few projects along the way from
PHP 5.6 to 8.0 over time (one was about this size, but it stopped at PHP
7.0 a few years back). They probably contain less "legacy code" since we
have strict conventions from the beginning, but we did migrate some
projects still.
Fact is, a legacy project cannot run without evolving if you want to
support a recent PHP version. The language itself evolves, and that's
for the best. Now for really legacy unmaintained projects, there's still
the solution to keep them running on deprecated PHP version using some
container technology. It's not ideal, but it can help until you finally
find the necessary resources to port.
Using a good static analysis tool and possibly some other tools such as
Rector, 130k lines is not an impossible goal.
I don't think there's an easy solution here, it's either don't upgrade,
or either refactor, but modern tooling should help you a lot with that.
If it can help you, can can still replace your array access using `$a =
$foo['bar'] ?? null` instead of `$a = \array_key_exists('bar', $foo) ?
$foo['bar'] : null`, it's both easier to read and write (you just store
` ?? null` in your clip board and hit paste on every use case you find).
Hope it helps,
Regards,
--
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
