Hi internals,
Now we have four functions that interact with extension name. ini_get_all() extension_loaded()
phpversion() and get_extension_funcs(). Among those, only ini_get_all is case-sensitive. That is:
extension_loaded(‘Pcre’) // ok
get_extension_funcs(‘Pcre’) // ok
phpversion(‘Pcre’) // ok
ini_get_all(‘Pcre’) // not ok
As proposed in GH-23293 [1] it is good to have ini_get_all consistent with other functions, that
is, to be case-insensitive in extension names. As per our current policy [2] A core developer
(David) requests that the feature to be discussed on the internals mailing list to make sure that
no one objects in the two-week period before this is merged.
Feel free to provide feedback if you think this change isn’t reasonable or could cause
compatibility issues 
Weilin
[1] https://github.com/php/php-src/pull/23293
[2] https://github.com/php/policies/blob/main/release-process.rst#feature-selection-and-development
Hi,
On Sat, 15 Aug 2026 at 17:42, Weilin Du <weilin-du@qq.com> wrote:
Hi internals,
Now we have four functions that interact with extension name. ini_get_all() extension_loaded()
phpversion() and get_extension_funcs(). Among those, only ini_get_all is case-sensitive. That is:
extension_loaded('Pcre') // ok
get_extension_funcs('Pcre') // ok
phpversion('Pcre') // ok
ini_get_all('Pcre') // not ok
As proposed in GH-23293 [1] it is good to have ini_get_all consistent with other functions, that
is, to be case-insensitive in extension names. As per our current policy [2] A core developer
(David) requests that the feature to be discussed on the internals mailing list to make sure that
no one objects in the two-week period before this is merged.
note I did not necessarily imply it needs to land for 8.6
Feel free to provide feedback if you think this change isn't reasonable or could cause
compatibility issues
Weilin
[1] Zend: Various refactor with `zend_hash_str_find_ptr_lc` by LamentXU123 · Pull Request #23293 · php/php-src · GitHub
[2] policies/release-process.rst at main · php/policies · GitHub
On Sat, Aug 15, 2026, at 18:39, Weilin Du wrote:
good to have ini_get_all consistent with other functions, that
is, to be case-insensitive in extension names.
I agree. Another option to make them consistent would be to have them all case-sensitive. Have you considered that?
On Sat, Aug 15, 2026, at 18:39, Weilin Du wrote:
get_extension_funcs(‘Pcre’) // ok
This is not what the documentation for get_extension_funcs says:
This parameter must be in lowercase.
This doesn’t seem to be true. Do you know why it says that?
Regards,
Sjoerd
On 2026-08-16 09:24, Sjoerd Langkemper wrote:
This is not what the documentation for get_extension_funcs says:
> This parameter must be in /lowercase/.
This doesn't seem to be true. Do you know why it says that?
Looking at the changelog for the get_extension_funcs docs page, and checking the historic output with 3v4l ( Online PHP editor | output for nKkZV ), it looks like this was the case in 5.0, but changed in 5.0.4
The docs commit references PHP :: Doc Bug #29169 :: get_extension_funcs() support for non-lowercase names
The documentation was right at the time it was amended to include this note, but appears to have got out of sync with reality later.
I did a quick scan / search of the NEWS for 5.0.4 but couldn't see the change mentioned there (but I could well have missed it)
Hi,
I don’t think making them all case-sensitive is better. Now, I understand that,
most people in 2026 like stricter parsing. I indeed do either.
However, PHP is in a stage in it’s lifecycle that it should take the BC break into serious
consideration. In this proposal, we “trade” consistency with BC breaks, and therefore I
want to keep the break effectively small. Changing three independent functions’
behavior is surely worse than one, and since we’ve already keep the “bad” habit of
processing case-insensitive extension names for decades, in my honest opinion it is
more reasonable to only fix the one case-sensitive case.
You’ve made a good point about the documentation. That’s a documentation error in
the get_extension_funcs function and should be fixed.
Considering branching: I don’t want to get 8.6 RMs in trouble of these small changes,
they surely doesn’t qualifies as a urgent feature that can be merged after the soft
feature freeze. Since I forget to make it clear: this should target 8.7
(Or, if 8.6 RMs want this to go into 8.6, please feel free to provide feedbacks)
Cheers to all!
Weilin
On Mon, Aug 17, 2026, at 12:10, Weilin Du wrote:
I don’t think making them all case-sensitive is better.
Yes, this sounds reasonable.
That’s a documentation error in
the get_extension_funcs function and should be fixed.
https://github.com/php/doc-en/issues/5765
this should target 8.7
How does this work with branches in git? Does this PR needs to stay open till the PHP-8.6 branch is created, before it can be merged into master? When is that?
Regards,
Sjoerd
Hi,
Il 17/08/2026 14:44, Weilin Du ha scritto:
The branch will be created a while after GA, that is at the end of Nov as far as a know.
If all goes according to plans the PHP-8.6 branch will be cut on Sept 22nd, a little over a month from now.
Never mind, we don't need to rush this anyways. I will create the PR after we branch out 8.6
It can wait, although I see no real BC issue in making ini_get_all() case insensitive. Either way, I'm fine with it.
Cheers
--
Matteo Beccati
On Tue, Aug 18, 2026 at 2:25 PM Weilin Du <weilin-du@qq.com> wrote:
Hi,
I don’t think making them all case-sensitive is better. Now, I understand that,
most people in 2026 like stricter parsing. I indeed do either.
However, PHP is in a stage in it’s lifecycle that it should take the BC break into serious
consideration. In this proposal, we “trade” consistency with BC breaks, and therefore I
want to keep the break effectively small. Changing three independent functions’
behavior is surely worse than one, and since we’ve already keep the “bad” habit of
processing case-insensitive extension names for decades, in my honest opinion it is
more reasonable to only fix the one case-sensitive case.
Wearing my hat as a core developer, I object to this change. We should be making them case-sensitive - BC breaks are serious, but we have an established procedure for them, which is deprecation (e.g. in 8.7) and then removal in the next major version. The break here is also trivial to fix - convert the string to the right casing, or use something like strtolower if the name should be lowercase.
Considering branching: I don’t want to get 8.6 RMs in trouble of these small changes,
they surely doesn’t qualifies as a urgent feature that can be merged after the soft
feature freeze. Since I forget to make it clear: this should target 8.7
(Or, if 8.6 RMs want this to go into 8.6, please feel free to provide feedbacks)
Cheers to all!
Weilin
Just to make it clear, since I wear another hat as the PHP 8.6 veteran release manager: my objection is as a normal developer, the view presented is my own and is unrelated to release management.
-Daniel
On Tue, Aug 18, 2026, at 14:35, Daniel Scherzer wrote:
We should be making them case-sensitive
Thanks for your feedback. Why do you think the module names should be case sensitive? What is the advantage of this?
Regards,
Sjoerd
Hi Daniel, Sjored
As I said I too think case-sensitive is better Now, my goal is consistency, so either
change it all to case-sensitive, or the opposite makes me happy. I just want to keep
the break small at the same time.
You’ve made a good point in deprecations that I haven’t taken into consideration of.
Surely, deprecations exists as a way to hold the BC break as small as possible for
changes, and that make sense to me. Now, given this idea, I’d lean to the case-sensitive
side because deprecations make the break small enough to me, and I don’t see the
advantage of this current proposal.
I don’t want to debate about why case-sensitive is better. I’d say its quite a common view
for today’s developers. Or maybe I am the only one thinking that way.
I will stop this proposal and add this (stop using case-insensitive extension names) to the
8.7 deprecation RFC later instead.
Weilin
On 18.08.2026 14:56, Weilin Du wrote:
I don't want to debate about why case-sensitive is better. I'd say its quite a common view
for today's developers. Or maybe I am the only one thinking that way.
I don't agree that case-sensitive here would be better.
There's multiple variations of extension names, e.g. PDO, SimpleXML, Xdebug, swoole.
And for example --disable-simplexml exists (btw, is this one case-insensitive? why not --disable-SimleXML?). The point is that in some places you don't have to know the exact casing. So, why would I have to know when checking for an extension existence?
More importantly, is it possible currently to have both Myext and myext enabled?
I'd say there might be more arguments for case-insensitive solution here.
--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Hi,
Il 18/08/2026 15:04, Aleksander Machniak ha scritto:
I don't agree that case-sensitive here would be better.
There's multiple variations of extension names, e.g. PDO, SimpleXML, Xdebug, swoole.
And for example --disable-simplexml exists (btw, is this one case- insensitive? why not --disable-SimleXML?). The point is that in some places you don't have to know the exact casing. So, why would I have to know when checking for an extension existence?
More importantly, is it possible currently to have both Myext and myext enabled?
I'd say there might be more arguments for case-insensitive solution here.
Wearing my RM hat, I've already mentioned that I'd be perfectly fine with 8.6 having a case‑insensitive `ini_get_all()`.
Wearing any other hat I might have, I agree that keeping extension names case‑insensitive makes far more sense.
Another example is `composer.json` and its `ext-*` dependencies, which are also generally written in their lowercase variants.
To me, this would be one of those useless BC breaks that make the user experience worse instead of improving it.
Cheers
--
Matteo Beccati
Another voice here for case- INsensitive. Case-sensitive makes no sense to me at all as the names of some extensions can be written in various different case-sensitive ways. Think: simplexml, Simplexml, SimpleXML, SimpleXml etc … Now, how would a dev know what the “proper” case is for a case-sensitive $extensions argument ? I can already hear people say - “oh, but those functions should not work on “proper” case, but should take lowercase extension names”… Except, now you want to create a “loaded extension version list” and you use get_loaded_extensions() and now you’d have to lowercase every extension name before passing it on to phpversion(). So, in my opinion, case-INsensitive for the $extensions arguments is the only thing that makes any sense and doesn’t make life harder for developers. And as a dev user without vote, I’d be perfectly fine for that change (making the $extensions parameter for ini_get_all() case-insensitive) to go into PHP 8.6 as a bug fix. Smile, Juliette
···
On 18-8-2026 16:51, Matteo Beccati wrote:
Il 18/08/2026 15:04, Aleksander Machniak ha scritto:
I don’t agree that case-sensitive here would be better.
There’s multiple variations of extension names, e.g. PDO, SimpleXML, Xdebug, swoole.
And for example --disable-simplexml exists (btw, is this one case- insensitive? why not --disable-SimleXML?). The point is that in some places you don’t have to know the exact casing. So, why would I have to know when checking for an extension existence?
More importantly, is it possible currently to have both Myext and myext enabled?
I’d say there might be more arguments for case-insensitive solution here.
Wearing my RM hat, I’ve already mentioned that I’d be perfectly fine with 8.6 having a case‑insensitive ini_get_all().
Wearing any other hat I might have, I agree that keeping extension names case‑insensitive makes far more sense.
To me, this would be one of those useless BC breaks that make the user experience worse instead of improving it.
Hi all,
Considering this proposal has controversial points, per our policy
this warrants a RFC process since at least one core developer objected.
I will launch the RFC process after 8.6 branch out since this surely
can’t catch the deadline. The RFC will propose the two mentioned
behaviors for the community to vote on in 8.7.
Thank everyone who participate in this matter.
Cheers,
Weilin.D