Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117039 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47109 invoked from network); 15 Feb 2022 11:38:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Feb 2022 11:38:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C148F1804A7 for ; Tue, 15 Feb 2022 04:55:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS16276 94.23.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 15 Feb 2022 04:55:54 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id 560EE5100317 for ; Tue, 15 Feb 2022 12:55:52 +0000 (UTC) Message-ID: <327daaee-01a9-631c-129a-7c8c89fddbb2@processus.org> Date: Tue, 15 Feb 2022 13:55:51 +0100 MIME-Version: 1.0 Content-Language: en-US To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] Setting to disable the "Undefined array index" warning From: pierre-php@processus.org (Pierre) 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