Adjust the summary which was too long.

You can already silence this warning in your own code using a custom error handler. See https://www.php.net/set_error_handler

You should however keep in mind that warnings tend to get escalated to errors over time (this was a notice since at least 5.4)

The null coalescing operator also provides an alternative "fix" that you may find more readable - like isset() it silences warnings about undefined indexes (and properties or variables): https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.null-coalesce-op

In the case you gave, you would write: if ($array['key'] ?? false)

I tried with a custom error handler. Something like:

if (strpos($errstr, 'Undefined index:') !== false OR strpos($errstr, 'Undefined offset:') !== false) return true;
else return false;

But it exhausts the memory before the end of the request.

As a rule of thumb, adding another php.ini option is not the right answer. What's more, adding one that tells PHP to ignore certain types of warnings/errors is opening a very big and very dangerous door that really ought to remain closed.

If your codebase is 10 years old then you'll have to accept that you cannot simply upgrade PHP versions (especially majors) and expect everything to work as it did back in 2011. PHP 7.4 is the last of the 7.x series and will remain in active support for an extended period - use that time to upgrade your codebase to be compatible with 8.x.

"is opening a very big and very dangerous door that really ought to remain closed"... funny. It's a door that's been wide open for many years. It would be helpful requinix, if you'd point us to an RFC or somethine where making this backward incompatible change has been decide instead of lecturing loyal developers. Also keeping them from running away to other languages as I did. Thanks.

Indeed it would be great to know why it is such a very dangerous door...

We still have not started to upgrade our codebase. We have 138627 lines of code to review just because of this "useless" warning. I will have to find a way to automate most of it, or spend weeks doing it…

Maybe I should have tried asking for more information before closing it. I'll start with a few easy questions.

#1. I have here a sample of 15 different warnings and notices: https://3v4l.org/l8pSY
Which of those should be suppressable by new php.ini settings? Or did I misunderstand, and the request is only about one very specific warning that should be handled with one very specific setting, with a steadfast opposition to the unintentional emergence of a "well we did it for X so why not do it for Y"-type precedent?

#2. Hypothetically, what about all the other sorts of warning and notices that are currently being raised throughout PHP? Are any of them also causing you undue problems as you attempt to update a 10 year old application that was developed in the days of PHP 5.3?
https://github.com/php/php-src/search?l=PHP&q=warning

#3. Given PHP's trend of turning suitable warnings into exceptions, should the settings also extend to suppressing the throwing of those exceptions? Or does it make more sense to spend time adding try/catch blocks to userland code (or, perhaps more sensibly, to disregard the possibility of exceptions entirely) than to wrap questionable array accesses in calls to empty()?

#4. Considering that you feel it is appropriate to ignore at least one type of warning across your application, do you think that PHP should simply remove nuisance warnings entirely and thus allow developers to ignore the sorts of problems they were intended to point out? Or are you concerned that there may be some number of unknown bugs that could be swept under the rug by a unilateral move to remove warnings for the sake of convenience?

#5. Have you heard of the @ operator? Unlike everything else in this reply, I really do mean to ask this without being facetious, as I believe this is likely the most appropriate solution to the problem.

Also, my apologies on behalf of all the PHP developers here for making the sudden decision that an attempt to access an undefined array key should now result in a warning, and for doing so without observing the RFC process by holding a public vote-- oh, wait, no, my bad, actually there was one about this.
https://wiki.php.net/rfc/engine_warnings

Unfortunately the discussion for that RFC was conducted privately between individuals with exclusive access to a secret mailing list that-- oh, nope, I'm sorry, that's not right either.
https://externals.io/message/106713

Thank you a lot for coming back to this.

#1. For me it is only the "Undefined array key" warning which is problematic. The best for me would be to simply return undefined (like in javascript) without warning or notice.

#2. Nope, only this one.

#3. For me, no matter if it is an exception, a warning or a notice, it should have a setting to accept this behavior.

#4. For this warning, I think that PHP should simply remove nuisance warnings entirely and thus allow developers to ignore the sorts of problems they were intended to point out.

#5. Yes, and it is not appropriate for us as we would have to use it at hundreds of places. We just want to be able to check if a property exists by accessing it, like this: `if ($array['key'])`. And this has been used everywhere in our code base. 

Here https://wiki.php.net/rfc/engine_warnings, we can see the 'Undefined array index' error was controversial. For us having them as notice is also problematic as we have to completely disable notices.

Thanks in advance for considering this request. I should have woken up earlier. If I can be of any help with this, please don't hesitate to ask.

If you want that warning to be (optionally) removed, please start
a discussion on the internals mailing list, and pursue the RFC
process[1].

[1] <https://wiki.php.net/rfc/howto>

Another alternative way of writing the same thing without warnings is using the "empty" pseudo-function:

if ( ! empty($array['key']) )

Like isset() and "??", it suppresses warnings for undefined vars and elements, and uses the same rules to define "emptiness" as the implicit boolean cast used in an if statement.

I think this version has some value in readability, particularly if $array['key'] is not in fact a boolean, e.g. if you're actually checking for "missing or empty string", or "uninitialised or empty list".