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,
Hi internals,
Now we have four functions that interact with extension name.
ini_get_all()extension_loaded()
phpversion()andget_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 okAs 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] https://github.com/php/php-src/pull/23293
[2] https://github.com/php/policies/blob/main/release-process.rst#feature-selection-and-development
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?
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
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 ( https://3v4l.org/nKkZV#veol ),
it looks like this was the case in 5.0, but changed in 5.0.4
The docs commit references https://bugs.php.net/bug.php?id=29169
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
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,
> 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?
The branch will be created a while after GA, that is at the end of Nov as far as a know.
Never mind, we don't need to rush this anyways. I will create the PR after we branch out 8.6 :)
Weilin
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 makingini_get_all()
case insensitive. Either way, I'm fine with it.
Cheers
Matteo Beccati
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
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
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
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‑insensitiveini_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.
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
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