Everything

php

Consistent case-insensitive module registry lookups

php.internals

weilin-du@qq.com

17 days ago

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.&nbsp;

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

David CARLIER

17 days ago

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 :)

Sjoerd Langkemper

16 days ago

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

AllenJB

16 days ago

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 ( 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)

weilin-du@qq.com

15 days ago

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.&nbsp;&nbsp;

You've made a good point about the documentation. That's a documentation error in
the&nbsp;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.&nbsp;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

Sjoerd Langkemper

15 days ago

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

weilin-du@qq.com

15 days ago

Hi,

&gt; 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

Matteo Beccati

15 days ago

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

Daniel Scherzer

14 days ago

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

Sjoerd Langkemper

14 days ago

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

weilin-du@qq.com

14 days ago

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

A.L.E.C

14 days ago

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

Matteo Beccati

14 days ago

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

Unnamed Person

14 days ago

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.

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

weilin-du@qq.com

12 days ago

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&nbsp;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&nbsp;