You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PHP 8.5 array_column Deprecation warning: Using null as an array offset is deprecated, use an empty string instead #25144
Deprecated: Using null as an array offset is deprecated, use an empty string instead in /x/y/z/test.php on line 16
Array ( [Inco] => Array ( [a] => Blaa [b] => Inco ) [] => Array ( [a] => XXX [b] => ) )
But I expected this output instead:
Array ( [Inco] => Array ( [a] => Blaa [b] => Inco ) [] => Array ( [a] => XXX [b] => ) )
If the intention is to blow up at this point in future PHP versions then it's going to add a lot of maintenance dev and extra overhead to fix it. To what advantage ?
If I'm going to have to loop through the array checking for nulls each time then I may as well dispense with array_column completely and write my own function - which will be nowhere near as performant as the existing PHP function.
PHP Version
PHP 8.5.12 (cli) (built: Oct 21 2026 14:36:25) (NTS)
Copyright (c) The PHP Group
Built by Ubuntu
Zend Engine v4.5.12, Copyright (c) Zend Technologies
with Zend OPcache v8.5.12, Copyright (c), by Zend Technologies
2. This deprecation was intentionally introduced in 49e3956 as part of the PHP 8.5 deprecations. See the changes.
I'm aware of that.
The point I am making is: If the intention is to blow up at this point in future PHP versions, it means I'm going to have to loop through the array checking for nulls each time so I may as well dispense with array_column completely and write my own function - which will be nowhere near as performant as the existing PHP function.
What's your solution ?
Thank you
The deprecation is related to using null as an array key, not to array_column() itself. Since array_column() uses the values from the specified index column as keys in the resulting array, a null value in that column triggers the deprecation.
To avoid it, you would need to normalize the keys before using array_column(). I understand your concern about the additional iteration and performance overhead.
4. The deprecation is related to using null as an array key, not to array_column() itself. Since array_column() uses the values from the specified index column as keys in the resulting array, a null value in that column triggers the deprecation.
To avoid it, you would need to normalize the keys before using array_column(). I understand your concern about the additional iteration and performance overhead.
Thanks for your commentary. What's the point of using array_column if I'm going to have to iterate the array anyway to prevent it blowing up on nulls in future PHP versions ? I may as well just re-write array_column so it carries on working as it has for the past 13 years ? Is there any other solution ?
Ideally you array shouldn't even be containing such values if you are going to use array_column, one of the many static analysis tools out there can help you identify the root cause.
6. array_column already blows up if you have invalid types: https://3v4l.org/GZi8D#v
Ideally you array shouldn't even be containing such values if you are going to use array_column, one of the many static analysis tools out there can help you identify the root cause.
As such I'm marking this as Won't fix.
I know exactly why there are nulls in the data. It's not going away. Goodbye array_column :-(
10. Does that mean you want it to do:
$arr ??= [];
print_r(array_combine(array_map(fn($b) => $b ?? '', array_column($arr, 'b')), $arr));
Many thanks for presenting a possible alternative.
It does use 3 functions to do the same thing as per array_column pre PHP 8.5 but with complex and pretty much unreadable code.
I'm wondering how it's going to be any more performant than writing a new safe_array_column function which iterates the array in a loop ?
It does use 3 functions to do the same thing as per array_column pre PHP 8.5 but with complex and pretty much unreadable code.
Yes, but silently casting NULL to an empty string was inconsistent with how it's treated everywhere else (which means continuing to do it would require custom code). I don't know where your nulls are coming from but could you convert them at source?
I never knew that array_column had support for objects as well as per the source code ?
The manual mentions:
array is treated as a list of rows, each of which is itself an array or an object; a column is the entry or property that column_key names in every row.
12. > It does use 3 functions to do the same thing as per array_column pre PHP 8.5 but with complex and pretty much unreadable code.
Yes, but silently casting NULL to an empty string was inconsistent with how it's treated everywhere else (which means continuing to do it would require custom code). I don't know where your nulls are coming from but could you convert them at source?
> I never knew that array_column had support for objects as well as per the source code ?
The manual mentions:
> array is treated as a list of rows, each of which is itself an array or an object; a column is the entry or property that column_key names in every row.
This was added in PHP 7.0.0.
Thank you for your commentary and the info about adding support for objects in PHP 7.0.0.
I greatly appreciate the community that continues to develop and support PHP. You guys rock. 🥇
I do notice the tendency to:
Read the manual at anybody who complains.
Blame users and their data when the PHP devs have actually "broken user space" (to quote Linus)
Tell users that it's not much work to upgrade their MASSIVE legacy codebases. Really ? Honestly ?
As soon as I have to loop through data to check for nulls which might blow up the application (if PHP 9.0?) then I may as well get rid of array_column and do it myself - because I cannot trust it not to blow up an entire application in production on a BIG legacy system.
At a deeper level, changing all those functions which stopped coercing nulls into empty strings just means everyone's code is now littered with this kind of noise:
$x=trim($myarray["a"] ?? "");
instead of
$x=trim($myarray["a"]);
What have we ACTUALLY gained ? Better debugging ? I'm happy to watch logs for E_WARNINGs in dev and production.
Lecturing everyone that $myarray["a"] should never be null is honestly an insulting nonsense. Are you suggesting that all database schemas should be updated so that nulls are never allowed ? That's insane and impractical. An everyday example is an integer column which could have a value of zero but ALSO needs to support null for logical reasons so should not be defaulted to zero.
It's up to me as the user how I want to run that. As I said earlier if I've got to start parsing nulls out of data to satisfy these requirements then I will have to bypass the native functions and do it myself - it will be more performant.
Seeing as PHP9 has not been released, I am going to be pushing as hard as I can that It should be my choice as a user about whether the language blows up at that point. Why oh why oh why is it necessary to inflict Fatals on us all in PHP9 ?
Pretty please ? With sugar on top ?
Shouting down the opposition is not collaboration. Silence is not acceptance.
Again: I greatly appreciate the community that continues to develop and support PHP. You guys rock. 🥇
Activity
arshidkv12 commentedon Nov 2, 2026
This deprecation was intentionally introduced in 49e3956 as part of the PHP 8.5 deprecations. See the changes.
clarumedia commentedon Nov 2, 2026
I'm aware of that.
The point I am making is: If the intention is to blow up at this point in future PHP versions, it means I'm going to have to loop through the array checking for nulls each time so I may as well dispense with array_column completely and write my own function - which will be nowhere near as performant as the existing PHP function.
What's your solution ?
Thank you
arshidkv12 commentedon Nov 2, 2026
The deprecation is related to using null as an array key, not to
array_column()itself. Sincearray_column()uses the values from the specified index column as keys in the resulting array, a null value in that column triggers the deprecation.To avoid it, you would need to normalize the keys before using
array_column(). I understand your concern about the additional iteration and performance overhead.clarumedia commentedon Nov 2, 2026
Thanks for your commentary. What's the point of using array_column if I'm going to have to iterate the array anyway to prevent it blowing up on nulls in future PHP versions ? I may as well just re-write array_column so it carries on working as it has for the past 13 years ? Is there any other solution ?
Girgias commentedon Nov 2, 2026
array_columnalready blows up if you have invalid types: https://3v4l.org/GZi8D#vIdeally you array shouldn't even be containing such values if you are going to use array_column, one of the many static analysis tools out there can help you identify the root cause.
As such I'm marking this as Won't fix.
clarumedia commentedon Nov 2, 2026
I know exactly why there are nulls in the data. It's not going away. Goodbye array_column :-(
MorganLOCode commentedon Nov 2, 2026
Does that mean you want it to do:
clarumedia commentedon Nov 3, 2026
Many thanks for presenting a possible alternative.
It does use 3 functions to do the same thing as per array_column pre PHP 8.5 but with complex and pretty much unreadable code.
I'm wondering how it's going to be any more performant than writing a new safe_array_column function which iterates the array in a loop ?
I never knew that array_column had support for objects as well as per the source code ?
https://github.com/php/php-src/blob/master/ext/standard/array.c#L4662
MorganLOCode commentedon Nov 3, 2026
Yes, but silently casting NULL to an empty string was inconsistent with how it's treated everywhere else (which means continuing to do it would require custom code). I don't know where your nulls are coming from but could you convert them at source?
The manual mentions:
This was added in PHP 7.0.0.
clarumedia commentedon Nov 4, 2026
Thank you for your commentary and the info about adding support for objects in PHP 7.0.0.
I greatly appreciate the community that continues to develop and support PHP. You guys rock. 🥇
I do notice the tendency to:
As soon as I have to loop through data to check for nulls which might blow up the application (if PHP 9.0?) then I may as well get rid of array_column and do it myself - because I cannot trust it not to blow up an entire application in production on a BIG legacy system.
At a deeper level, changing all those functions which stopped coercing nulls into empty strings just means everyone's code is now littered with this kind of noise:
$x=trim($myarray["a"] ?? "");
instead of
$x=trim($myarray["a"]);
What have we ACTUALLY gained ? Better debugging ? I'm happy to watch logs for E_WARNINGs in dev and production.
Lecturing everyone that $myarray["a"] should never be null is honestly an insulting nonsense. Are you suggesting that all database schemas should be updated so that nulls are never allowed ? That's insane and impractical. An everyday example is an integer column which could have a value of zero but ALSO needs to support null for logical reasons so should not be defaulted to zero.
It's up to me as the user how I want to run that. As I said earlier if I've got to start parsing nulls out of data to satisfy these requirements then I will have to bypass the native functions and do it myself - it will be more performant.
Seeing as PHP9 has not been released, I am going to be pushing as hard as I can that It should be my choice as a user about whether the language blows up at that point. Why oh why oh why is it necessary to inflict Fatals on us all in PHP9 ?
Pretty please ? With sugar on top ?
Shouting down the opposition is not collaboration. Silence is not acceptance.
Again: I greatly appreciate the community that continues to develop and support PHP. You guys rock. 🥇
Thank you