#externals

[RFC] Partial Function Application: Handling of Optional Parameters

Mon, 04 May 2026 07:12:30 +0000

Am 2026-04-21 19:52, schrieb Tim Düsterhus:

Please find all details in the RFC at:
https://wiki.php.net/rfc/partial_function_application_optional_placeholder

Unless significant discussion happens, I expect the RFC to go to vote
in 2 weeks, so that it can be incorporated in the PFA implementation
right away.

Tomorrow very exciting two weeks of discussion will have passed. I plan
to open voting later this week.

Best regards
Tim Düsterhus

[RFC] [Discussion] `#[\Override]` for class constants

Mon, 04 May 2026 02:48:08 +0000

Hi internals,

It has been more than 14 days, so the cooldown period is over. Having
received no further feedback, this is your official intent to vote message

I plan to open the vote in the next few days if there are no new concerns.

-Daniel

On Sat, Apr 18, 2026 at 6:19 PM Daniel Scherzer daniel.e.scherzer@gmail.com
wrote:

Hi internals,

I have updated the RFC to resolve the open issue about #[\Override] on
enum cases - when marked with #[\Override], the enum case must be
overriding an inherited class constant. The fact that this is so uncommon
makes it all the more important that when it is intentional, it can be made
clear.

This qualifies as a "major change" to the RFC and triggers a 14 day
cooldown period.

-Daniel

On Mon, Mar 30, 2026 at 4:36 PM Daniel Scherzer <
daniel.e.scherzer@gmail.com> wrote:

Hi internals,

I'd like to start the discussion for a new RFC about adding support for
#[\Override] for class constants.

RFC: https://wiki.php.net/rfc/override_constants

Implementation: https://github.com/php/php-src/pull/20478

I'd also like to draw specific attention to the open question, which I am
soliciting feedback on: how should #[\Override] work for enum cases? See
the RFC page for details.

Thanks,
-Daniel

[VOTE] Secure Session Configuration Defaults

Sun, 03 May 2026 19:40:38 +0000

Thank Ayesh, and I'm sorry for skipping this option. It's been added now.

Kind regards,
Jorg

[VOTE] Secure Session Configuration Defaults

Sun, 03 May 2026 15:49:56 +0000

I'm opening up the vote on this RFC.

Wiki page: https://wiki.php.net/rfc/session_security_defaults

There are three votes to cast, and the voting will end on
2026-05-18 00:00:00 UTC.

Hi Jorg,
The votes must also contain an "Abstain" option.

Thank you,
Ayesh.

[RFC] Release Manager Selection

Sun, 03 May 2026 15:29:20 +0000

Hi

Am 2026-03-27 19:15, schrieb Tim Düsterhus:

please find the following RFC that is intended to clarify the
“Release Manager Selection” policy for future PHP versions:

https://wiki.php.net/rfc/release_manager_selection_policy

I've made some changes to the PR to streamline the language a little
more and use consistent terminology to refer to various “relative” PHP
versions (e.g. “upcoming PHP version” for the PHP version that we're
going to elect RMs for).

Please check the commits for more details.

I consider this a major change. Given how quiet this discussion was, I
plan to vote on the RFC once the cooldown period expires. I'll send an
official intent to vote when this date comes closer.

Best regards
Tim Düsterhus

I still dislike the distinction of "hands-on" and "hands-off" as
descriptors for these roles and disagree with their use in defining
these roles. I said as much in my earlier message, and I'll be voting
"no" for the changes to the policy as it currently stands.

I think I'm in agreement with the rest of the proposal. If we can come
up with better terminology around the roles and make the roles less
about their level of involvement, then I'll probably change my vote to a
"yes."

Cheers,
Ben

Following up on my earlier messages, I've been thinking more about the
terminology and have come up with a concrete suggestion.

From my perspective, the distinction between the two roles is
fundamentally about experience, not involvement. I don't want to define
the roles around involvement. The policy itself already uses the word
"veteran" to describe the qualification for the advisory role, so I'd
suggest elevating that to the name of the role itself: "Veteran Release
Manager" for the advisor with prior experience, and "Co-release Manager"
for the other two. This reuses terminology already present in the policy
text and defines the roles by what qualifies someone for them rather
than what they're expected to do or not do. It also leaves room for the
RMs themselves to organize their work as they see fit.

With these changes I'd be comfortable changing my vote to "yes."

Cheers,
Ben

[RFC] Release Manager Selection

Sun, 03 May 2026 14:40:11 +0000

Hi

Am 2026-03-27 19:15, schrieb Tim Düsterhus:

please find the following RFC that is intended to clarify the “Release
Manager Selection” policy for future PHP versions:

https://wiki.php.net/rfc/release_manager_selection_policy

I've made some changes to the PR to streamline the language a little
more and use consistent terminology to refer to various “relative” PHP
versions (e.g. “upcoming PHP version” for the PHP version that we're
going to elect RMs for).

Please check the commits for more details.

I consider this a major change. Given how quiet this discussion was, I
plan to vote on the RFC once the cooldown period expires. I'll send an
official intent to vote when this date comes closer.

Best regards
Tim Düsterhus

I still dislike the distinction of "hands-on" and "hands-off" as
descriptors for these roles and disagree with their use in defining
these roles. I said as much in my earlier message, and I'll be voting
"no" for the changes to the policy as it currently stands.

I think I'm in agreement with the rest of the proposal. If we can come
up with better terminology around the roles and make the roles less
about their level of involvement, then I'll probably change my vote to a
"yes."

Cheers,
Ben

[VOTE] Secure Session Configuration Defaults

Sun, 03 May 2026 14:35:18 +0000

Sure. Link to the discussion:
https://news-web.php.net/php.internals/130608
https://externals.io/message/130608#130689

Sorry, for missing it.

Kind regards,
Jorg

[VOTE] Secure Session Configuration Defaults

Sun, 03 May 2026 14:26:54 +0000

Hello internals,
I'm opening up the vote on this RFC.

Wiki page: https://wiki.php.net/rfc/session_security_defaults

There are three votes to cast, and the voting will end on
2026-05-18 00:00:00 UTC.

Kind regards,
Jorg

Under the References section of the RFC, would you mind providing a link
to the relevant mailing list discussion? I can't find the discussion,
and I'd like to see what others have said about the proposal. I would
consider this an editorial change, so it shouldn't affect the voting
timeline (i.e., you don't need to stop the vote and restart it).

According to the voting procedure rules, your voting announcement email
must also include a link to the discussion thread. Again, simply
replying here with the link should suffice.

https://github.com/php/policies/blob/main/feature-proposals.rst#voting-procedure

Cheers,
Ben

`COM_RESET_CONNECTION` support in `mysqlnd`

Sun, 03 May 2026 14:14:35 +0000

A single RFC with two primary votes to independently resolve each of the
two cases (at the same time) would work. Given the concerns and the
similarity between both, I don't think we can do without an RFC.

Fair enough. I'd appreciate your collaboration on this RFC if you're
amenable! I've started a draft here:
https://wiki.php.net/rfc/min_supported_versions_php_8_6.

I have a few things to note:

I wasn't sure how to approach the merger of the two topics. I
decided to model this like the various deprecation RFCs, in that we're
deciding on a slate of minimum supported software for PHP 8.6.
Ideally, if people objected to the MySQL minimum version for
persistent connections, I'd be able to include a vote that allowed for
an INI setting.
Related to that: I'm not sure how much detail to add about the
actual implementation I'd like for persistent connections. Is this a
vote for my specific implementation, or just the higher-level concept
of requiring a certain version of software in PHP 8.6? My goal is to
ship this, so needing to do two RFCs back-to-back would be annoying.

Feel free to respond privately if you'd like to take this off-list. Thanks!

[RFC] Release Manager Selection

Sun, 03 May 2026 13:11:56 +0000

Am 2026-03-27 19:15, schrieb Tim Düsterhus:

please find the following RFC that is intended to clarify the “Release
Manager Selection” policy for future PHP versions:

https://wiki.php.net/rfc/release_manager_selection_policy

I've made some changes to the PR to streamline the language a little
more and use consistent terminology to refer to various “relative” PHP
versions (e.g. “upcoming PHP version” for the PHP version that we're
going to elect RMs for).

Please check the commits for more details.

I consider this a major change. Given how quiet this discussion was, I
plan to vote on the RFC once the cooldown period expires. I'll send an
official intent to vote when this date comes closer.

Best regards
Tim Düsterhus

[VOTE] Secure Session Configuration Defaults

Sun, 03 May 2026 13:08:12 +0000

Hello internals,
I'm opening up the vote on this RFC.

Wiki page: https://wiki.php.net/rfc/session_security_defaults

There are three votes to cast, and the voting will end on
2026-05-18 00:00:00 UTC.

Kind regards,
Jorg

`COM_RESET_CONNECTION` support in `mysqlnd`

Sun, 03 May 2026 12:01:03 +0000

Am 2026-04-30 16:11, schrieb Eric Norris:

Somewhat relatedly, see:
https://github.com/php/php-src/pull/21159#issuecomment-4111691063. I
think it would be good to decide both cases at the same time, since
they
are reasonably similar.

That could make sense, and how would you suggest we proceed to decide
the case? I'll admit that I'd be hesitant to need to resolve that via
an RFC, since if the RFC failed I'd need to potentially make another
RFC just for my change + some INI setting, and so it'd be quite some
time until I could get this merged. That's not to say we shouldn't do
it, I'm just noting my hesitation.

A single RFC with two primary votes to independently resolve each of the
two cases (at the same time) would work. Given the concerns and the
similarity between both, I don't think we can do without an RFC.

Best regards
Tim Düsterhus

[RFC] __exists(), a magic method for distinguishing "missing" from "set to null"

Sat, 02 May 2026 20:17:31 +0000

Hi Larry,

Le sam. 2 mai 2026 à 17:47, Larry Garfield larry@garfieldtech.com a
écrit :

Dear internals,

It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-method

TL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;
It'd let userland tell "set to null" apart from "missing" on objects,
it'd restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695
as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
via method_exists()), and would be magic on 8.6+.

Cheers,
Nicolas
Thanks for the very detailed RFC!

If it returns false, the fetch produces “uninitialized” (treated as null
by ??, so y is evaluated). __get() is not called.

What is y? Looks like a reference to a previous iteration of the text.

The Sequencing section also doesn't describe the behavior when __exists()
isn't defined. Does it just skip to step 4? (Please specify in the text.)

Is the intent to eventually deprecate __isset()? The RFC it doesn't now,
but do you feel that is the eventual end-game, in PHP 10 or whatever?

The big one: Should any parallel changes or additions be made to property
hooks? An exists() operation in addition to get/set, for instance? (I'm
not sure at the moment, but it should be thought through and discussed, and
if not, documented in the RFC.)

Thanks for having a look!

I made some changes to clarify, see:
https://wiki.php.net/rfc/exists-magic-method?do=diff&rev2%5B0%5D=1777627745&rev2%5B1%5D=1777752909&difftype=sidebyside

y => $y
I added a description of the current sequencing of magic methods.
About deprecating __isset, I think it's way too early to consider doing it
for real. Still my answer is yes, but not on any timescale I can
anticipate. I added words about the doc, which should now encourage
__exists IMHO.
About hooks, that deserves a separate RFC to me. I've no intuition on this
as I don't use hooks often enough to feel the need for any missing "exists"
hook. If you still want my noob take on this: a hooked property exists -
because it has hooks. Not super helpful :D I added some words about this in
the RFC.

Cheers,
Nicolas

[RFC] Remove the links to X.com from PHP.net

Sat, 02 May 2026 20:16:16 +0000

Hey Jakub, Hey All

Hi,

Hey Larry, hey all.

I've drafted an alternative RFC that addresses this directly:

https://wiki.php.net/rfc/social-media-policy
https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/changes

It establishes Infrastructure Team custody of credentials (with
succession procedures, so this situation does not recur) and
Foundation content authority for official channels. Decisions about
which platforms PHP maintains become content decisions within a
documented process — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability
of either this "Infrastructure Team", and the "temporary
administration" of The PHP Foundation itself has continued to fail to
deliver on its nearly five-year-old promise to establish governance
procedures of its own, and it appears to be content to continue
operating that way indefinitely, so I don't believe it is in the
interest of the PHP project to wait for that.

I'd ask that this RFC be deferred until the governance framework is in
place. Removing a link is trivial to do afterwards, should that be the
decision.

Respectfully, no. The governance framework we have now is the RFC
process, and even if you want to characterize this as ratifying a
decision that was made unilaterally by someone, doing that by RFC is
the process we have.

Cheers.

Jim

I fully agree with Jim here. I am 100% in favor of improving our
governance processes, which are currently largely non-existent. I will
happily support those efforts, but they're so haphazard right now that we
need to start at ground 0 first; defining the infra team, how one is added
to it, how one is removed from it, etc. That's a not-small task; one I'm
happy to assist in, but it's a months long process knowing PHP.

Meanwhile, the current process, broken as it is, does have a mechanism
to approve "don't link to this thing," and it's called an RFC. We work
with the process we have, not the process we wish we had. And the process
we have is exactly this thread/RFC, as-is.

Sorry to disagree here.

The current process to add or remove things from the PHP website is not
RFC but Nike-based: Just do it.

And "don't link to this thing on the website because it is outdated and
nothing new is coming" should be a no-brainer. We had other things
removed that were much less outdated.

As soon as there is an objection (which was the case in that PR). RFC is
the only mechanism that we have to resolve such disagreement. So it’s
correctly used for the website link part.

Again I'd like to disagree.

The "objection" on the PR in question1 was not whether we should
remove the link to to an account that has been inactive for several
years on X but whether we should have a presence on X (for whoever "we"
is. Personal note: Certainly not me)

No single comment on that PR objected to the removal of the link.

In that PR I have several times tried to keep the topics separate.

One is: Shall PHP have a presence on X
Second is: Shall the PHP presence on X be actively managed
Third is: Shall we right now link to a presence on X that is no
longer actively maintained (for whatever reason) and that gives the
impression PHP has stopped doing anything since the release of PHP8.3 on
the 23rd of November 2023.

The PR only targets the third topic!

I find it hilarious that we can not decide upon right now removing a
link to a currently not active presence on the internet!

Removing this link is not as if it is set in stone! Once we get the
presence back online we can at any time re-add the link.

The PR does not target topics one and two! Whether we need an RFC
for those or whatever else is totally not what I am concerned about!
Let's deal with those separately from the PR!

But let'S get to the point where we can decide upon right now
removing a link to a resource that SCREAMS "410 Gone"

And when that resource is back again, let's hope that readding the link
doesn't need to be signed in triplicate, sent in, sent back, queried,
lost, found, subjected to public inquiry, lost again, and finally buried
in soft peat for three months and recycled as firelighters.

My 0.02 €

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+

[RFC] Remove the links to X.com from PHP.net

Sat, 02 May 2026 19:39:38 +0000

Hi,

Hey Larry, hey all.

I've drafted an alternative RFC that addresses this directly:

https://wiki.php.net/rfc/social-media-policy
https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/changes

It establishes Infrastructure Team custody of credentials (with
succession procedures, so this situation does not recur) and
Foundation content authority for official channels. Decisions about
which platforms PHP maintains become content decisions within a
documented process — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability
of either this "Infrastructure Team", and the "temporary
administration" of The PHP Foundation itself has continued to fail to
deliver on its nearly five-year-old promise to establish governance
procedures of its own, and it appears to be content to continue
operating that way indefinitely, so I don't believe it is in the
interest of the PHP project to wait for that.

I'd ask that this RFC be deferred until the governance framework is in
place. Removing a link is trivial to do afterwards, should that be the
decision.

Respectfully, no. The governance framework we have now is the RFC
process, and even if you want to characterize this as ratifying a
decision that was made unilaterally by someone, doing that by RFC is
the process we have.

Cheers.

Jim

I fully agree with Jim here. I am 100% in favor of improving our
governance processes, which are currently largely non-existent. I will
happily support those efforts, but they're so haphazard right now that we
need to start at ground 0 first; defining the infra team, how one is added
to it, how one is removed from it, etc. That's a not-small task; one I'm
happy to assist in, but it's a months long process knowing PHP.

Meanwhile, the current process, broken as it is, does have a mechanism
to approve "don't link to this thing," and it's called an RFC. We work
with the process we have, not the process we wish we had. And the process
we have is exactly this thread/RFC, as-is.

Sorry to disagree here.

The current process to add or remove things from the PHP website is not
RFC but Nike-based: Just do it.

And "don't link to this thing on the website because it is outdated and
nothing new is coming" should be a no-brainer. We had other things
removed that were much less outdated.

As soon as there is an objection (which was the case in that PR). RFC is
the only mechanism that we have to resolve such disagreement. So it’s
correctly used for the website link part.

The question whether we want to have a presence and whether we want to
try to get that specific presence back online is a different question
and yes! I am with you there: That is something for an RFC. Regardles
whether that is Mastodon, Instagram, X, Facebook, LinkedIn or any other
commercial "social media".

This is actually matter for policy RFC IMO so it should be completely
removed from this RFC unless there is a policy update PR. I don’t think it
will have any long term impact otherwise because we follow only processes
defined in the policy repo. It was too messy to try to collect it from all
those process rfc so we decided for that repo for exactly that reason.

This also applies to Roman’s RFC. It should be policy repo first approach.

Kind regards,

Jakub

[VOTE] Display Function Arguments in Errors

Sat, 02 May 2026 18:10:23 +0000

I'm opening up the vote on this RFC.

Wiki page: https://wiki.php.net/rfc/display_error_function_args
Internals thread: https://externals.io/message/130290

There are three votes to cast, and the voting should end on
2026-05-15T21:00:00Z.

Regards,
Calvin

The 3rd voting widget appears to still be closed.

--Larry Garfield

I fixed the vote here; looks like it was just an unclosed quote.

[RFC] Remove the links to X.com from PHP.net

Sat, 02 May 2026 16:18:07 +0000

Hey Larry, hey all.

I've drafted an alternative RFC that addresses this directly:

https://wiki.php.net/rfc/social-media-policy
https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/changes

It establishes Infrastructure Team custody of credentials (with
succession procedures, so this situation does not recur) and
Foundation content authority for official channels. Decisions about
which platforms PHP maintains become content decisions within a
documented process — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability
of either this "Infrastructure Team", and the "temporary
administration" of The PHP Foundation itself has continued to fail to
deliver on its nearly five-year-old promise to establish governance
procedures of its own, and it appears to be content to continue
operating that way indefinitely, so I don't believe it is in the
interest of the PHP project to wait for that.

I'd ask that this RFC be deferred until the governance framework is in
place. Removing a link is trivial to do afterwards, should that be the
decision.

Respectfully, no. The governance framework we have now is the RFC
process, and even if you want to characterize this as ratifying a
decision that was made unilaterally by someone, doing that by RFC is
the process we have.

Cheers.

Jim

I fully agree with Jim here. I am 100% in favor of improving our governance processes, which are currently largely non-existent. I will happily support those efforts, but they're so haphazard right now that we need to start at ground 0 first; defining the infra team, how one is added to it, how one is removed from it, etc. That's a not-small task; one I'm happy to assist in, but it's a months long process knowing PHP.

Meanwhile, the current process, broken as it is, does have a mechanism to approve "don't link to this thing," and it's called an RFC. We work with the process we have, not the process we wish we had. And the process we have is exactly this thread/RFC, as-is.

Sorry to disagree here.

The current process to add or remove things from the PHP website is not
RFC but Nike-based: Just do it.

And "don't link to this thing on the website because it is outdated and
nothing new is coming" should be a no-brainer. We had other things
removed that were much less outdated.

The question whether we want to have a presence and whether we want to
try to get that specific presence back online is a different question
and yes! I am with you there: That is something for an RFC. Regardles
whether that is Mastodon, Instagram, X, Facebook, LinkedIn or any other
commercial "social media".

And re-adding the link then should then not be much of an issue at all.

Right now though the link is sending people to an outdated profile
implying that PHP is outdated and nothing new came for the last few years...

Cheers

Andreas

[RFC] Remove the links to X.com from PHP.net

Sat, 02 May 2026 15:54:37 +0000

I've drafted an alternative RFC that addresses this directly:

https://wiki.php.net/rfc/social-media-policy
https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/changes

It establishes Infrastructure Team custody of credentials (with
succession procedures, so this situation does not recur) and
Foundation content authority for official channels. Decisions about
which platforms PHP maintains become content decisions within a
documented process — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability
of either this "Infrastructure Team", and the "temporary
administration" of The PHP Foundation itself has continued to fail to
deliver on its nearly five-year-old promise to establish governance
procedures of its own, and it appears to be content to continue
operating that way indefinitely, so I don't believe it is in the
interest of the PHP project to wait for that.

I'd ask that this RFC be deferred until the governance framework is in
place. Removing a link is trivial to do afterwards, should that be the
decision.

Respectfully, no. The governance framework we have now is the RFC
process, and even if you want to characterize this as ratifying a
decision that was made unilaterally by someone, doing that by RFC is
the process we have.

Cheers.

Jim

I fully agree with Jim here. I am 100% in favor of improving our governance processes, which are currently largely non-existent. I will happily support those efforts, but they're so haphazard right now that we need to start at ground 0 first; defining the infra team, how one is added to it, how one is removed from it, etc. That's a not-small task; one I'm happy to assist in, but it's a months long process knowing PHP.

Meanwhile, the current process, broken as it is, does have a mechanism to approve "don't link to this thing," and it's called an RFC. We work with the process we have, not the process we wish we had. And the process we have is exactly this thread/RFC, as-is.

--Larry Garfield

[VOTE] Display Function Arguments in Errors

Sat, 02 May 2026 15:47:12 +0000

I'm opening up the vote on this RFC.

Wiki page: https://wiki.php.net/rfc/display_error_function_args
Internals thread: https://externals.io/message/130290

There are three votes to cast, and the voting should end on
2026-05-15T21:00:00Z.

Regards,
Calvin

The 3rd voting widget appears to still be closed.

--Larry Garfield

[RFC] __exists(), a magic method for distinguishing "missing" from "set to null"

Sat, 02 May 2026 15:44:56 +0000

Dear internals,

It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-method

TL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;
It'd let userland tell "set to null" apart from "missing" on objects,
it'd restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695
as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
via method_exists()), and would be magic on 8.6+.

Cheers,
Nicolas

Thanks for the very detailed RFC!

If it returns false, the fetch produces “uninitialized” (treated as null by ??, so y is evaluated). __get() is not called.

What is y? Looks like a reference to a previous iteration of the text.

The Sequencing section also doesn't describe the behavior when __exists() isn't defined. Does it just skip to step 4? (Please specify in the text.)

Is the intent to eventually deprecate __isset()? The RFC it doesn't now, but do you feel that is the eventual end-game, in PHP 10 or whatever?

The big one: Should any parallel changes or additions be made to property hooks? An exists() operation in addition to get/set, for instance? (I'm not sure at the moment, but it should be thought through and discussed, and if not, documented in the RFC.)

--Larry Garfield

Propose changes to warning message in declare(encoding=...) when encoding is not a multibye-required encoding method

Sat, 02 May 2026 08:50:21 +0000

Hi internals,

I am writing to ask for suggestions in bug Issue #21538 in php-src 1. Currently when zend.multibyte=0, declare(encoding=...) will emit a warning for whatever the encoding is:

"PHP Warning: declare(encoding=...) ignored because Zend multibyte feature is turned off by settings in XXX"

And the problem is when the encoding is ASCII or UTF-8, which is, not a multibyte encoding method, the warning will still be emitted. So, if zend.multibyte=0 and you use files with declare(encoding=ASCII) it will emit the error message to make people want to remove them.

Now, since declare(encoding=UTF-8) behaves identically whether zend.multibyte is on or off, the warning is quite misleading. Also I think people might mostly use them as documenting codes to tell tools how to decode them because when zend.multibyte=0, PHP already parses source files as UTF-8 by default.

However, it is also reasonable to say people might want to use these warnings to check if their code bases have useless codes.

So I would suggest to change the warning message in those cases to

“PHP Warning: declare(encoding='UTF-8(or ASCII)') is useless, remove it.”

to make things clearer.

This would be a very minor change and do not worth a separate RFC. However, I think it is still important to send a email to gather opinions :) Also thank @alexdowad for giving me ideas. TiA :)

--Weilin Du

[RFC] [Discussion] array_get and array_has functions

Sat, 02 May 2026 07:28:14 +0000

Hi

Am 2026-04-25 21:37, schrieb Barel:

Many thanks for your comments regarding the RFC, I have updated it.

I'm seeing you adjusted the text to mention “If any segment is not a
string or integer: throw a TypeError, even if that segment would not be
reached”. This is however not reflected in the example implementation.

Thanks for pointing this out. This has been updated in the RFC

Carlos

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 19:10:33 +0000

I've drafted an alternative RFC that addresses this directly:

https://wiki.php.net/rfc/social-media-policy
https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/changes

It establishes Infrastructure Team custody of credentials (with
succession procedures, so this situation does not recur) and
Foundation content authority for official channels. Decisions about
which platforms PHP maintains become content decisions within a
documented process — including the X question, future platforms, and
any reversal of those decisions later.

This doesn't do anything to establish the membership and accountability of either this "Infrastructure Team", and the "temporary administration" of The PHP Foundation itself has continued to fail to deliver on its nearly five-year-old promise to establish governance procedures of its own, and it appears to be content to continue operating that way indefinitely, so I don't believe it is in the interest of the PHP project to wait for that.

I'd ask that this RFC be deferred until the governance framework is in
place. Removing a link is trivial to do afterwards, should that be the
decision.

Respectfully, no. The governance framework we have now is the RFC process, and even if you want to characterize this as ratifying a decision that was made unilaterally by someone, doing that by RFC is the process we have.

Cheers.

Jim

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 18:54:37 +0000

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there
This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

Do you really need more details about why X/Twitter is a problem per se? This subject has already been covered in several threads: its owner is a fascist that promotes and enhances fascism with the help of his networks, he deliberately updated the recommendation algorithm to create a personality-cult for his fame, the AI that's bound to this network is p*do-promoting, most of the people that are still there are either fascism-enthusiasts or compliant with what the platform has become (therefore, okay with the statu quo, which means "collaborating with the in-place system").

Great -- if those are the beliefs of the RFC author, they should go
directly in the RFC as supporting language for the reasoning behind the
RFC.

Then there's a record of exactly who is voting in agreement with those
statements, and who is not.

If there is some worry or concern about adding the reasons, that itself
will be quite telling.

I don't think I have been coy about the reasons at all, but I have updated the RFC. I'll consider this a major change, so voting will happen after the 14-day cooling period. (So I will send another message about the intent to call the vote in about a week.)

Cheers.

Jim

[VOTE] Display Function Arguments in Errors

Fri, 01 May 2026 15:33:07 +0000

I'm opening up the vote on this RFC.

Wiki page: https://wiki.php.net/rfc/display_error_function_args
Internals thread: https://externals.io/message/130290

There are three votes to cast, and the voting should end on
2026-05-15T21:00:00Z.

Regards,
Calvin

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 15:05:16 +0000

Hi all,

On May 1, 2026, at 05:27, Alex Pierstoval Rock pierstoval@gmail.com
wrote:

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the
project to have a presence there

This is unclear -- what exactly about "the current nature of the site"
leads to there being "no reason for the project to have a presence there" ?
Can you articulate the specifics, for the record, in the PR?

-- pmj

Do you really need more details about why X/Twitter is a problem per se?
This subject has already been covered in several threads: its owner is a
fascist that promotes and enhances fascism with the help of his networks,
he deliberately updated the recommendation algorithm to create a
personality-cult for his fame, the AI that's bound to this network is
p*do-promoting, most of the people that are still there are either
fascism-enthusiasts or compliant with what the platform has become
(therefore, okay with the statu quo, which means "collaborating with the
in-place system").

Great -- if those are the beliefs of the RFC author, they should go
directly in the RFC as supporting language for the reasoning behind the RFC.

Then there's a record of exactly who is voting in agreement with those
statements, and who is not.

If there is some worry or concern about adding the reasons, that itself
will be quite telling.

-- pmj

I agree with Paul.

--
Chase Peeler
chasepeeler@gmail.com
https://linktr.ee/chasepeeler

[RFC] [Discussion] Followup Improvements for ext/uri

Fri, 01 May 2026 13:57:37 +0000

Hi Máté and all,

I have no issue with the usage of namespaced functions, on the contrary I
think that they do give a better understanding of the intended API usage.
It is a self contained feature which is fully decoupled from the main URI
classes with 0 side-effects.

My main goal has always been to provide a better UX over having static
methods on the main URI classes.

As you pointed out, adding percent-decoding in a later stage seems
reasonable to me, if we can find a way in the meantime to remove the
mis-usage
or mis-understanding you highlighted then at that point adding a new
function will then be a no-brainer. So there will be no pushed back from my
part around
this change.

In the meantime, I have already updated my polyfill to be inline with your
last changes. As I said earlier, the fact that the introduced Enums can not
be instantiated
from an URI makes their presence in the polyfill required but incomplete as
they can not be used before PHP8.6 since the URI classes are final and no
named
constructors can be attached to them to allow their instantiation from an
actual URI instance.

see https://github.com/thephpleague/uri-src/pull/170/changes

Looking forward to your call for voting and its outcome.

Regards,
Ignace

Hi Ignace, Tim et al.,

I've finished updating the RFC once again, after some private discussion
with Tim:

It turned out that the percent-decoding feature as proposed would have led
to confusing behavior
in some cases. In order to avoid this, I ultimately removed the
percent-decoding support from the
proposal. In the same time, I pivoted from the "instance methods on an
enum” based approach
to a simple namespaced function based solution, because the enums would
only ever have a single
method (even if decoding support is added later, possibly not all the
(Uri|Url)PercentEncoder enum cases
would be applicable for decoding). Let me know if this doesn't work for
you, TBH adding namespaced
functions was my least favorite solution, but I didn't have any
significantly better idea which would have had
the potential to gain traction.

I have called out one example in the RFC (
https://wiki.php.net/rfc/uri_followup#percent-encoding_support) which
would be problematic if we had a Uri\Rfc3986\uri_percent_decode()
function, so let me copy-paste it here for reference:

$uri = new Uri\Rfc3986\Uri("https://example.com/?a=b%26c"); // The query
is the percent-encoded form of "a=b&c=d"

echo Uri\Rfc3986\uri_percent_decode(
$uri->getQuery(),
Uri\Rfc3986\UriPercentEncodingMode::Query
);
// a=b&c

The result is probably not what we expected, because percent-decoding
changed the meaning of the query component:

Originally, the query contained a parameter “a” with value “b%26c”
(“b&c”)

Now, there is a parameter “a” with value “b”, as well as a parameter “c”
without value

And I'm now attempting once again to announce my intention to start the
vote:
If no significant issue comes up this time, then I'll start the vote next
Tuesday evening (according to UTC).

Regards,
Máté

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 13:35:01 +0000

On Fri, May 1, 2026, 9:32 AM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:

However, I don't understand why unlinking this X account from php.net
should wait for all of the bureaucracy to play out first.

For one thing, removing the link doesn't actually solve the problem. The
account is still there for people to find, marked "official", under the
control of someone who disputes the right of the project to control it.

If nobody was offering to tackle the problem, it would be a stop-gap, but
Roman is offering to tackle it.

I'm not against removing the link, if it's otherwise unanimous, but it
seems wasteful to have two parallel debates on the same topic.

Rowan Tommins
[IMSoP]

If I read between the lines correctly, the person who currently controls
the account doesn't dispute the right of the project to control it, rather
the right of the project sans a method of governance to control it.

If that's an accurate read, the RFC to establish governance, should it be
approved, would solve both issues.

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 13:28:53 +0000

However, I don't understand why unlinking this X account from php.net
should wait for all of the bureaucracy to play out first.

For one thing, removing the link doesn't actually solve the problem. The account is still there for people to find, marked "official", under the control of someone who disputes the right of the project to control it.

If nobody was offering to tackle the problem, it would be a stop-gap, but Roman is offering to tackle it.

I'm not against removing the link, if it's otherwise unanimous, but it seems wasteful to have two parallel debates on the same topic.

Rowan Tommins
[IMSoP]

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 12:42:16 +0000

Hi all,

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there

This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

Do you really need more details about why X/Twitter is a problem per se? This subject has already been covered in several threads: its owner is a fascist that promotes and enhances fascism with the help of his networks, he deliberately updated the recommendation algorithm to create a personality-cult for his fame, the AI that's bound to this network is p*do-promoting, most of the people that are still there are either fascism-enthusiasts or compliant with what the platform has become (therefore, okay with the statu quo, which means "collaborating with the in-place system").

Great -- if those are the beliefs of the RFC author, they should go directly in the RFC as supporting language for the reasoning behind the RFC.

Then there's a record of exactly who is voting in agreement with those statements, and who is not.

If there is some worry or concern about adding the reasons, that itself will be quite telling.

-- pmj

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 12:09:23 +0000

I'm all for addressing the long-term governance issue, and I don't think
anyone else has objected to that.

However, I don't understand why unlinking this X account from php.net
should wait for all of the bureaucracy to play out first. The account has
been inactive (or at least hasn't posted anything) for over a decade it
seems, and is currently a liability. To me it's a no-brainer to remove the
link now, and only add it back if/when the situation is resolved.

Agreed, let's remove stale/dead account and then separately formulate a
social media policy (platforms, ownership, responsibility). I think some
"political messaging" was added to the original RFC, which caused the
confusion.

--
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 11:56:41 +0000

Hi,

On Fri, May 1, 2026 at 2:18 PM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:

The account is silent because one credential holder unilaterally
stopped posting and has not transferred or shared access despite
repeated requests. That is a governance failure, not a project
decision. Removing the link in this context does not reflect a project
consensus to abandon the platform — it ratifies the outcome of one
person's unilateral action.

I agree with Roman here: even if there was unanimous agreement that the X
account should be shut down, we would need to proceed in stages:

Agree how official PHP social media accounts should be governed, and
who should have access.

Based on that policy, demand access to the X account called
"php_official" be transferred.

Based on that process, decide whether the X account should be shut
down, and if so, what that should look like (e.g. complete account
deletion, or profile update to link to other active channels).

Otherwise, we're just setting ourselves up for more problems in future:
people creating "official" accounts on other services, then abandoning
them, or worse.

I'm all for addressing the long-term governance issue, and I don't think
anyone else has objected to that.

However, I don't understand why unlinking this X account from php.net
should wait for all of the bureaucracy to play out first. The account has
been inactive (or at least hasn't posted anything) for over a decade it
seems, and is currently a liability. To me it's a no-brainer to remove the
link now, and only add it back if/when the situation is resolved.

Cheers,
Andrey.

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 11:15:35 +0000

The account is silent because one credential holder unilaterally
stopped posting and has not transferred or shared access despite
repeated requests. That is a governance failure, not a project
decision. Removing the link in this context does not reflect a project
consensus to abandon the platform — it ratifies the outcome of one
person's unilateral action.

I agree with Roman here: even if there was unanimous agreement that the X account should be shut down, we would need to proceed in stages:

Agree how official PHP social media accounts should be governed, and who should have access.
Based on that policy, demand access to the X account called "php_official" be transferred.
Based on that process, decide whether the X account should be shut down, and if so, what that should look like (e.g. complete account deletion, or profile update to link to other active channels).

Otherwise, we're just setting ourselves up for more problems in future: people creating "official" accounts on other services, then abandoning them, or worse.

Regards,

Rowan Tommins
[IMSoP]

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 10:37:31 +0000

Do you really need more details about why X/Twitter is a problem per se?

Quote from How To Create an RFC page (https://wiki.php.net/rfc/howto):

Listen to the feedback, and try to answer/resolve all questions. Update
your RFC to document all the issues and discussions. Cover both the
positive and negative arguments.

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 10:31:34 +0000

Since PHP is community-driven, maybe instead it could be interesting to
create a global PHP-community-wide poll, aside of the "php people with
voting rights", to gather more sentiment on whether there should be a
"social media policy", or at least to know whether PHP as an "organized
community with a lead account" (somehow) should be present on X, or on
certain other platforms.

That would help some people like me and others to definitely show
whether we are a niche amount of people agreeing on the fact that PHP
should leave X, or if there are actual people who care about the image
of the language being active on a fascist platform.

[RFC] Remove the links to X.com from PHP.net

Fri, 01 May 2026 10:27:50 +0000

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there
This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

Do you really need more details about why X/Twitter is a problem per se?
This subject has already been covered in several threads: its owner is a
fascist that promotes and enhances fascism with the help of his
networks, he deliberately updated the recommendation algorithm to create
a personality-cult for his fame, the AI that's bound to this network is
p*do-promoting, most of the people that are still there are either
fascism-enthusiasts or compliant with what the platform has become
(therefore, okay with the statu quo, which means "collaborating with the
in-place system").

[RFC] __exists(), a magic method for distinguishing "missing" from "set to null"

Fri, 01 May 2026 09:37:43 +0000

Dear internals,

It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-method

TL;DR: I'm proposing a new opt-in magic method:

public function __exists(string $name): bool;

It'd let userland tell "set to null" apart from "missing" on objects, it'd
restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695 as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
via method_exists()), and would be magic on 8.6+.

Cheers,
Nicolas

[RFC] Stream Error Handling Improvements

Thu, 30 Apr 2026 21:46:31 +0000

Hi,

Hello,

I would like to introduce a new stream error handling RFC that is part of
my stream evolution work (PHP Foundation project funded by Sovereign Tech
Fund) :

https://wiki.php.net/rfc/stream_errors

Just a heads up that I plan to open voting on this on Sun 3rd May.

Cheers

Jakub

[RFC] Remove the links to X.com from PHP.net

Thu, 30 Apr 2026 20:56:08 +0000

Hi Jim & all,

Currently, the RFC states:

due to to the current nature of the site, there is no reason for the project to have a presence there

This is unclear -- what exactly about "the current nature of the site" leads to there being "no reason for the project to have a presence there" ? Can you articulate the specifics, for the record, in the PR?

-- pmj

[RFC] [Discussion] Followup Improvements for ext/uri

Thu, 30 Apr 2026 19:19:11 +0000

Hi Ignace, Tim et al.,

I've finished updating the RFC once again, after some private discussion
with Tim:

It turned out that the percent-decoding feature as proposed would have led
to confusing behavior
in some cases. In order to avoid this, I ultimately removed the
percent-decoding support from the
proposal. In the same time, I pivoted from the "instance methods on an
enum” based approach
to a simple namespaced function based solution, because the enums would
only ever have a single
method (even if decoding support is added later, possibly not all the
(Uri|Url)PercentEncoder enum cases
would be applicable for decoding). Let me know if this doesn't work for
you, TBH adding namespaced
functions was my least favorite solution, but I didn't have any
significantly better idea which would have had
the potential to gain traction.

I have called out one example in the RFC (
https://wiki.php.net/rfc/uri_followup#percent-encoding_support) which
would be problematic if we had a Uri\Rfc3986\uri_percent_decode() function,
so let me copy-paste it here for reference:

$uri = new Uri\Rfc3986\Uri("https://example.com/?a=b%26c"); // The query
is the percent-encoded form of "a=b&c=d"

echo Uri\Rfc3986\uri_percent_decode(
$uri->getQuery(),
Uri\Rfc3986\UriPercentEncodingMode::Query
);
// a=b&c

The result is probably not what we expected, because percent-decoding
changed the meaning of the query component:

Originally, the query contained a parameter “a” with value “b%26c” (“b&c”)
Now, there is a parameter “a” with value “b”, as well as a parameter “c”
without value

And I'm now attempting once again to announce my intention to start the
vote:
If no significant issue comes up this time, then I'll start the vote next
Tuesday evening (according to UTC).

Regards,
Máté

PHP 8.5.6RC3 available for testing

Thu, 30 Apr 2026 18:28:11 +0000

PHP 8.5.6RC3 has just been released and may be downloaded from
https://downloads.php.net/~daniels/

Or use the git tag: php-8.5.6RC3

Windows binaries are available at:
https://www.php.net/pre-release-builds.php#windows

Please test it carefully, and report any bugs at
https://github.com/php/php-src/issues

8.5.6 should be expected in 1 week, i.e. on the 7 May 2026.

Hash values and PGP signatures can be found below or at
https://gist.github.com/DanielEScherzer/f7b0c9da6228a0422c18a136c4394864

If you're curious as to why we needed to have another release candidate, or
why that release candidate is 3 instead of 2, I wrote up an explanation on
my
blog:
https://scherzer.dev/Blog/20260430-php856-rc-3

Thank you, and happy testing!

Regards,
Daniel Scherzer, Volker Dusch, and Pierrick Charron

php-8.5.6RC3.tar.bz2
SHA256 hash:
7084b65f8a37558950a657654d0cabda0778d9c3b49f1c79a16bf2c9611d109b
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmnysVsACgkQdORLyQZ3
AaUPAw/+Jt/QJl/2DgSw9R0FOdLsCM54Py9MKMX9LguXNw2xHXL7J3gg+MjyuN+M
zOZHWWAMVNtOtUmKAYidCEmdcB7wGtoDbZzYus3j3Zy6T7zqJk5LtvWmRn0PzXn+
ziJyHEeZTZoBorP3AZ/vAy+BVaN15LpsGyn83EYhpYYHikaboYMwLJh4894v+745
0khjSOOJmJSPQAgblnKc4D3ZtWXV9/QqZlhl3PognQjCVa8xC/BblrHC7qgnc2vg
vS2FVtEfb9ttAt2mC5TX/4ojJlX8YKbZ2j5JPoiUAUAnfdku+MyD0X3tOWDQ2Mpt
J3fB+wR78vRa/KyyyS8PDOpQ7EqzZjtRmMO3RO5/WZiPMeRNtwbRgUgKg2re77iI
jh4NXGfqMjUtLKNW5d8Gr9L00vSUWmPnr5+diruacHAViP+LXdbN3mUSqdifTQy6
3hdN1ZtOpzvWoeT99vCzJzwqP8db1NJ4yyg6UpH1jILlrmkwLwEPDqvVShVm5jGT
g8CgDq0pb/gnM2N2wFN+SoAQqMiLIbGoUj6zUDgqJ/0GWTRRTP08F1Hj79d1zf39
SFuylG8JB156NYYcr/8pfQevh3rQbgwF1zREoM8HnCec0ftw0Wj7UgUfxca/O4vs
tvXNDCHl03A1JOjXROi5kS+7DfRhHDXwwJsVzmbwfXlk02KEEKs=
=GiDn
-----END PGP SIGNATURE-----

php-8.5.6RC3.tar.gz
SHA256 hash:
01e12f91a9c6924d42d208a1d97a32930562caa410f49f0caae62e07bfe014ff
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmnysWAACgkQdORLyQZ3
AaUzFg//Y9d6qQRYlOXQfE1esb5OMR6nADlk2yS4ZHaznT8bdEBv5erveA5uYHLI
ALowCKzsw9NT0hEW17QAgDuTZtx6ZZWPHseM4tZaSvoyMaFe46EA9xmsfSU/hhHr
Ifum7PaVqBOW4u6Yx4GUxSypE5ClJmaqN4qFFoktzbrwHd6jkJdk5bWEZ7Wq3k9i
CHW/177b40MyQsnC2Ao+Rdvk6QcSZFKWMMAelZTenVPwCQQdsEb3Bh9RK1VCfPIb
CbY53cPkQynYardfmwuSCAssqashk8w9bizG/hCZkhdsye9FUz1jq6V0zZTDLk8Z
qG8zH6eE49nOk9vDKIqZpDb/t4De8F48KsiaeMIZYCAZddtlYNzX0CWQqBAPGVCq
k/ChOTXFFlAMZfh1QwKzeThJTwxFSyo0F27umKlcWgpA061I6ewPNFhHHyhf2HaZ
ezvvD6IzSYC1hFXHTAVUFusBjVON15tWr1dmdzXVvu2+qEVQnS64AbnbNWMvVGGO
g79XhNPnk/37N+6wUhL22umAABDYQTCNcfVBD9BhslmTmSQaeYdaAUg3wK5N8Vha
TslCELkUrTAUAz0j6/JMCck5r8GiOcKcnOhf83eMOYcnoEanCbxw86ERYQFevMVx
O2JlA25+W53oZ0WqF7iLAc8m5dBZD9PtRe873SydTPbYCbYCYiE=
=rm9G
-----END PGP SIGNATURE-----

php-8.5.6RC3.tar.xz
SHA256 hash:
5faeca2a67e766f897a51c7a93414706d168d75c862f86343f6c4658c318eee5
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmnysWAACgkQdORLyQZ3
AaXgbxAAtuAZ6dcuxD8Av3D9Bp5XYE+IBLQukILgPzus8pyfCBjzzDkIh8W2pEVm
7tIJjD1v8s2/YT1X3HpArOG2p/VRWih7jd+jiyowmyojeYnCdEwgls2+97muKyB2
GJzkJsPeOOnbJTwWKN6ZOx4ZpA15+3cPsWw2GBscmAX0IDucCGkYa1Qn3rwqOjVp
l6TgewvpWQQM2QRfv1yxUmOaXFhtQAcrRTWxYNI8I+b5ggXIeqkOxS2CH9M45RQv
ShiH+qOC8MA/3/EM3P5aOO+5WlIz6jUqy+dAsLcUr/aRfgBo4CyP27gEwlh6a8Bp
Hp1mAqmD/6Rt5evyA8skDbE5WZPrHb7MW5xdTUEbmuNwBM6tHHBH1cTlBRVWyGtB
vTSw1h3MxlnXlv3w+1GUttwEjUvwXQRlg1ojTp0CMClcShNsqN5xJUTAQG6gGCIV
QxuMKeAqBSaz7fTI1b0FNou4DSg3XH3n+Sa8cgSWuLD/OotAZLnHY/UKFHD4eiVS
/Qc7sP5aDjj5NU5dZHO5+/0yzXnblbEI8AXY/XhUOtKoi69hzaq5lMgVV+9z5hJr
yOuSuqEYG5txVt+jQSI2yEXttps3Lx2v6u25xkXrJxDNMeujgDXEJFfSsSSj8lB/
wh05EfE+pZGtZ/ZFzfoPWe3W8VejaZOFMahrcJQszWr1LqJvzFk=
=D8/g
-----END PGP SIGNATURE

[RFC] Remove the links to X.com from PHP.net

Thu, 30 Apr 2026 15:59:29 +0000

Removing the link in this context does not reflect a project
consensus to abandon the platform — it ratifies the outcome of one
person's unilateral action.

Leaving Xitter would be appreciated though: some people do in fact give a
damn.

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

[RFC] Remove the links to X.com from PHP.net

Thu, 30 Apr 2026 15:55:00 +0000

https://wiki.php.net/rfc/remove-link-to-x-from-php-net

The RFC describes the account as dormant and implies the project has
chosen not to post on X. Neither is accurate as stated.

The account is silent because one credential holder unilaterally
stopped posting and has not transferred or shared access despite
repeated requests. That is a governance failure, not a project
decision. Removing the link in this context does not reflect a project
consensus to abandon the platform — it ratifies the outcome of one
person's unilateral action.

That precedent matters beyond X: it establishes that any credential
holder for any project asset can force a project-wide outcome by
simply becoming non-responsive. The link will be removed, the account
will be marked as no longer official, and the underlying procedural
failure gets retroactively legitimized as a "decision".

Larry mentioned earlier in this thread that PHP has never had formal
procedures for defining "official" accounts. The correct response to
that observation is to establish those procedures, not to treat their
absence as license for any individual outcome that happened to result.

The link itself represents a project-level commitment that one person
should not be able to unilaterally undo through inaction. Until the
credentials question is resolved through a defined process, removing
the link records the wrong outcome and embeds the wrong precedent.

I've drafted an alternative RFC that addresses this directly:

https://wiki.php.net/rfc/social-media-policy
https://github.com/pronskiy/php-rfc-social-media-policy/pull/1/changes

It establishes Infrastructure Team custody of credentials (with
succession procedures, so this situation does not recur) and
Foundation content authority for official channels. Decisions about
which platforms PHP maintains become content decisions within a
documented process — including the X question, future platforms, and
any reversal of those decisions later.

I'd ask that this RFC be deferred until the governance framework is in
place. Removing a link is trivial to do afterwards, should that be the
decision.

-Roman

`COM_RESET_CONNECTION` support in `mysqlnd`

Thu, 30 Apr 2026 14:11:58 +0000

Hi

Am 2026-04-27 20:09, schrieb Eric Norris:

Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think.

I agree that it is a reasonable expectation from users to use the latest
(or at least: a supported) version of third party software when they
want to use the latest PHP version. Especially since my understanding is
that in this instance, the communication would also not be broken
entirely, but users would just need to disable persistent connections,
no? This means if they want to upgrade PHP, without being able to
upgrade their MySQL version they would potentially need to give up some
performance optimization, but other than that it would work unchanged?

That's a great point, and correct - users can still upgrade, they just
will need to give up persistent connections.

Somewhat relatedly, see:
https://github.com/php/php-src/pull/21159#issuecomment-4111691063. I
think it would be good to decide both cases at the same time, since they
are reasonably similar.

That could make sense, and how would you suggest we proceed to decide
the case? I'll admit that I'd be hesitant to need to resolve that via
an RFC, since if the RFC failed I'd need to potentially make another
RFC just for my change + some INI setting, and so it'd be quite some
time until I could get this merged. That's not to say we shouldn't do
it, I'm just noting my hesitation.

Pre-RFC discussion about adding friendship to PHP

Thu, 30 Apr 2026 14:08:01 +0000

Hi internals,

I'd like to add support for friendship in PHP. I don't mean friendship
in the PSR-8 huggable way,

Aw, but why not?

but rather in the C++ way of allowing access
to non-public parts of a class without needing to use Reflection.

I haven't started work on implementing this yet, but there is a big
question about how to indicate friendship that I wanted to get some
feedback on. Specifically, should it be added with a new keyword, or
with an attribute?

Keyword

matches C++

suggests that friends are aspects of the class, like properties and
constants and methods

but would look a bit ugly if we added support for friends that are
just for specific properties/methods/constants

Attribute

matches how other metadata is added to classes

would make it look cleaner if subsequently support was added for
friendship being applied to specific properties/methods/constants

would differ from the current builtin attributes in that it doesn't
just add/remove warnings, but changes some functionality

For a more in-depth explanation of the inspiration and these two
potential approaches, see
https://scherzer.dev/Blog/20260309-php-friends. To be clear, I have not
yet written an implementation, much less the RFC, but I wanted to get
some initial feedback on if people would prefer a new keyword, or an
attribute, for declaring friends.

-Daniel

There was a lot of related discussion around module/package/file visibility not too long ago that is also worth reviewing. Currently I am highly skeptical of friend classes, as I believe module-level visibility is more useful than class-level, in general.

That said, were we to go this route, I agree that keywords would be the way to go for the reasons given in the blog post. Also, there's some plumbing already i place via aviz, at least for properties. In concept, the following should be possible:

class User {
friend UserFactory;

public friend(set) string $name;
}

class UserFactory {
public function makeUser($name) {
$u = new User();
$u->name = $name; // This is OK, because UserFactory is a friend.
return $u;
}
}

$factory = new UserFactory();
$u = $factory->makeUser('Larry');

print $u->name; // OK, because public get
$u->name = 'Daniel'; // Error, because not a friend.

Whether that makes sense to extend to methods, I don't know.

--Larry Garfield

Pre-RFC discussion about adding friendship to PHP

Thu, 30 Apr 2026 10:59:57 +0000

Hi internals,

I'd like to add support for friendship in PHP. I don't mean friendship in the PSR-8 huggable way, but rather in the C++ way of allowing access to non-public parts of a class without needing to use Reflection.

I haven't started work on implementing this yet, but there is a big question about how to indicate friendship that I wanted to get some feedback on. Specifically, should it be added with a new keyword, or with an attribute?

Keyword

matches C++

suggests that friends are aspects of the class, like properties and constants and methods

but would look a bit ugly if we added support for friends that are just for specific properties/methods/constants

Attribute

matches how other metadata is added to classes

would make it look cleaner if subsequently support was added for friendship being applied to specific properties/methods/constants

would differ from the current builtin attributes in that it doesn't just add/remove warnings, but changes some functionality

For a more in-depth explanation of the inspiration and these two potential approaches, see https://scherzer.dev/Blog/20260309-php-friends. To be clear, I have not yet written an implementation, much less the RFC, but I wanted to get some initial feedback on if people would prefer a new keyword, or an attribute, for declaring friends.

-Daniel

Hi Daniel,

We saw some friendship discussions in my nested class RFC, where nested classes implicitly became friends of the outer class. I'd recommend checking those threads for feedback about friendship and scope.

— Rob

[RFC] Context Managers

Thu, 30 Apr 2026 07:52:26 +0000

Am 2026-04-30 09:42, schrieb Rob Landers:

I'd argue CMs are mechanisms, not policies. They encode setup and
teardown. Suppression is an error-handling policy decision that should
be visible at the call site, not mixed with the concerns of setting up
and tearing down resources.

I agree here and noted something similar in the “RAII vs Context
Manager” thread: https://news-web.php.net/php.internals/129463 (last
paragraph).

Best regards
Tim Düsterhus

`COM_RESET_CONNECTION` support in `mysqlnd`

Thu, 30 Apr 2026 07:49:32 +0000

Am 2026-04-27 20:09, schrieb Eric Norris:

Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think.

I agree that it is a reasonable expectation from users to use the latest
(or at least: a supported) version of third party software when they
want to use the latest PHP version. Especially since my understanding is
that in this instance, the communication would also not be broken
entirely, but users would just need to disable persistent connections,
no? This means if they want to upgrade PHP, without being able to
upgrade their MySQL version they would potentially need to give up some
performance optimization, but other than that it would work unchanged?

Somewhat relatedly, see:
https://github.com/php/php-src/pull/21159#issuecomment-4111691063. I
think it would be good to decide both cases at the same time, since they
are reasonably similar.

Best regards
Tim Düsterhus

Pre-RFC discussion about adding friendship to PHP

Thu, 30 Apr 2026 07:43:26 +0000

Am 2026-04-29 19:30, schrieb Daniel Scherzer:

I haven't started work on implementing this yet, but there is a big
question about how to indicate friendship that I wanted to get some
feedback on. Specifically, should it be added with a new keyword, or
with
an attribute?

It should be a proper keyword for the reasons that are also mentioned in
your blog post: Attributes are not part of the public API and thus do
not contribute to e.g. LSP checks. They are also expected to gracefully
degrade when they do not exist, which means that running code written
with friendship in mind on older PHP versions will silently expose a
different API instead of failing in a visible way.

See also the reasoning that I provided in the #[\Override] RFC:
https://wiki.php.net/rfc/marking_overriden_methods#why_an_attribute_and_not_a_keyword.
I think the related mailing list discussion provides additional context

and I seem to remember I wrote something similar in some other RFC
discussion as well.

Best regards
Tim Düsterhus

[RFC] Context Managers

Thu, 30 Apr 2026 07:42:24 +0000

I think a key question to answer here is: Do we care to differentiate between CM errors and underlying errors?

I don't think we need to differentiate at the CM level. Suppression is
a policy decision that belongs to the caller, not the context manager.
The CM's job is cleanup: rollback the transaction, close the file,
release the lock, etc. Whether the exception continues propagating
after that is the caller's call, and try using already provides
exactly that:

try using ($db->transaction() => $conn) {
$conn->execute('INSERT INTO orders ...');
} catch (ValidationException $e) {
// Caller chooses to suppress this here
}

That makes exitContext() simple: return void, do your cleanup, and
get out. If cleanup fails, it throws naturally, and the desugared form
can chain the original exception as $previous so the root cause isn't
lost. If the caller wants to suppress or differentiate, they already
have try using for exactly that.

It's worth noting that every example in the RFC (database transactions,
file locks, error handler swaps, async scopes) does cleanup and
propagates. None of them actually need the power to suppress. If a
context manager wants to give callers a clean exception hierarchy to
catch against, it can wrap underlying exceptions in their own types
during cleanup. That's just normal exception design, no special syntax
required.

— Rob

Just to make sure I'm following you, you're arguing that a CM should not have any way at all to suppress an exception? I don't think I'd agree with that, personally. Even if it's a rare case, I do believe it's a feature that should remain.

I'd argue CMs are mechanisms, not policies. They encode setup and teardown. Suppression is an error-handling policy decision that should be visible at the call site, not mixed with the concerns of setting up and tearing down resources.

If CM's could suppress arbitrary exceptions, from a developer stepping over the code, they'd see the code randomly appear to jump out of the using block after a suppressed exception ... at seemingly arbitrary points. There would be no way to trust what you were reading without having the CM's code in front of you as well.

— Rob

[RFC] [Discussion] array_get and array_has functions

Thu, 30 Apr 2026 07:34:51 +0000

Am 2026-04-25 21:37, schrieb Barel:

Many thanks for your comments regarding the RFC, I have updated it.

I'm seeing you adjusted the text to mention “If any segment is not a
string or integer: throw a TypeError, even if that segment would not be
reached”. This is however not reflected in the example implementation.

Best regards
Tim Düsterhus

PS: Don't forget to cut your quotes when replying :-)

Pre-RFC discussion about adding friendship to PHP

Wed, 29 Apr 2026 17:30:33 +0000

Hi internals,

I'd like to add support for friendship in PHP. I don't mean friendship in
the PSR-8 huggable way, but rather in the C++ way of allowing access to
non-public parts of a class without needing to use Reflection.

I haven't started work on implementing this yet, but there is a big
question about how to indicate friendship that I wanted to get some
feedback on. Specifically, should it be added with a new keyword, or with
an attribute?

Keyword

matches C++
suggests that friends are aspects of the class, like properties and
constants and methods
but would look a bit ugly if we added support for friends that are just
for specific properties/methods/constants

Attribute

matches how other metadata is added to classes
would make it look cleaner if subsequently support was added for
friendship being applied to specific properties/methods/constants
would differ from the current builtin attributes in that it doesn't just
add/remove warnings, but changes some functionality

For a more in-depth explanation of the inspiration and these two potential
approaches, see https://scherzer.dev/Blog/20260309-php-friends. To be
clear, I have not yet written an implementation, much less the RFC, but I
wanted to get some initial feedback on if people would prefer a new
keyword, or an attribute, for declaring friends.

-Daniel

[RFC] Context Managers

Wed, 29 Apr 2026 15:04:55 +0000

I think a key question to answer here is: Do we care to differentiate between CM errors and underlying errors?

I don't think we need to differentiate at the CM level. Suppression is
a policy decision that belongs to the caller, not the context manager.
The CM's job is cleanup: rollback the transaction, close the file,
release the lock, etc. Whether the exception continues propagating
after that is the caller's call, and try using already provides
exactly that:

try using ($db->transaction() => $conn) {
$conn->execute('INSERT INTO orders ...');
} catch (ValidationException $e) {
// Caller chooses to suppress this here
}

That makes exitContext() simple: return void, do your cleanup, and
get out. If cleanup fails, it throws naturally, and the desugared form
can chain the original exception as $previous so the root cause isn't
lost. If the caller wants to suppress or differentiate, they already
have try using for exactly that.

It's worth noting that every example in the RFC (database transactions,
file locks, error handler swaps, async scopes) does cleanup and
propagates. None of them actually need the power to suppress. If a
context manager wants to give callers a clean exception hierarchy to
catch against, it can wrap underlying exceptions in their own types
during cleanup. That's just normal exception design, no special syntax
required.

— Rob

Just to make sure I'm following you, you're arguing that a CM should not have any way at all to suppress an exception? I don't think I'd agree with that, personally. Even if it's a rare case, I do believe it's a feature that should remain.

--Larry Garfield

[RFC] Context Managers

Wed, 29 Apr 2026 14:30:57 +0000

I think a key question to answer here is: Do we care to differentiate between CM errors and underlying errors?

I don't think we need to differentiate at the CM level. Suppression is a policy decision that belongs to the caller, not the context manager. The CM's job is cleanup: rollback the transaction, close the file, release the lock, etc. Whether the exception continues propagating after that is the caller's call, and try using already provides exactly that:

try using ($db->transaction() => $conn) {
$conn->execute('INSERT INTO orders ...');
} catch (ValidationException $e) {
// Caller chooses to suppress this here
}

That makes exitContext() simple: return void, do your cleanup, and get out. If cleanup fails, it throws naturally, and the desugared form can chain the original exception as $previous so the root cause isn't lost. If the caller wants to suppress or differentiate, they already have try using for exactly that.

It's worth noting that every example in the RFC (database transactions, file locks, error handler swaps, async scopes) does cleanup and propagates. None of them actually need the power to suppress. If a context manager wants to give callers a clean exception hierarchy to catch against, it can wrap underlying exceptions in their own types during cleanup. That's just normal exception design, no special syntax required.

— Rob

[RFC] Context Managers

Wed, 29 Apr 2026 13:15:20 +0000

Am 2026-04-22 20:28, schrieb Larry Garfield:

Ways of handling a single method's returns

Possible ways to do so off the top of my head, in no particular order:

I don't currently have the time to digest this email in detail, but I
wanted to mention an alternative you didn't before I forget: Making the
exception an in-out parameter. That would be functionally similar to a
return value, but more strongly default to “don't make a change”,
because “doing nothing” will just work.

i.e.

 public function exitContext(?\Throwable &$e): void {
     // Assign null to suppress.
     $e = null;
 }

Best regards
Tim Düsterhus

RFC karma request

Tue, 28 Apr 2026 15:46:16 +0000

Hi Roman

I kindly request RFC Karma for my wiki account pronskiy.

I'd like to publish a proposal on Social Media and Marketing
Communications Policy:
https://gist.github.com/pronskiy/995feaf238cd7ae33c7d2461cd929d70

RFC karma was granted. Good luck!

Ilija

RFC karma request

Tue, 28 Apr 2026 15:16:27 +0000

Hi internals,

I kindly request RFC Karma for my wiki account pronskiy.

I'd like to publish a proposal on Social Media and Marketing
Communications Policy:
https://gist.github.com/pronskiy/995feaf238cd7ae33c7d2461cd929d70

-Roman

`COM_RESET_CONNECTION` support in `mysqlnd`

Mon, 27 Apr 2026 18:09:48 +0000

Hello everyone!

I've created a PR to send COM_RESET_CONNECTION in mysqlnd when
reusing a persistent connection [1]. This ensures that the connection
is in a blank-slate state, and not possibly in a transaction or
operating with any variables set from a previous request, etc.

Tim had opened a GitHub issue for this a while back [2]. A user
commented there to point out that COM_RESET_CONNECTION is supported
in MySQL 5.7.3+ and MariaDB 10.2+, and so my implementation would
necessitate at least those versions as a minimum supported version.

Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think. Notably, if we were to
implement configuration for this we'd likely need to introduce yet
another INI variable; I have an impression that PHP maintainers are
somewhat skeptical of adding new INI settings.

Secondly, I'm curious what people think about implementing this in
both PDO and mysqlnd. In PDO, we can replace the liveness check
with this command, which would act as both a liveness check and a
reset for no additional round-trip cost.

Please take a look and let me know what you think. I would like to
think this is something that is possible without submitting an RFC,
but of course if people feel that is necessary I'm able to go that
route.

Thanks!

[1] https://github.com/php/php-src/pull/21857
[2] https://github.com/php/php-src/issues/20225

[RFC] Display Function Arguments in Errors

Mon, 27 Apr 2026 16:05:44 +0000

Hi internals,

Based on the feedback I had from my proposal for function arguments in
errors last week, I'd like to introduce an RFC for it. Please let me
know what you think and please raise any possible issues.

https://wiki.php.net/rfc/display_error_function_args

Regards,
Calvin

Per feature-proposals, this is an Intent to Vote message.

I intend to start the vote on Friday, around the evening in Europe.

[RFC] Remove the links to X.com from PHP.net

Sun, 26 Apr 2026 23:19:01 +0000

Any response about reasonable alternative RFC?
https://gist.github.com/pronskiy/995feaf238cd7ae33c7d2461cd929d70

My response is that if Roman wants to propose his own RFC and have it discussed here, he knows where the list is.

Jim

PHP Foundation Discord channel

Sun, 26 Apr 2026 22:23:43 +0000

Hi everyone

Quick heads-up: phpc.chat has graciously allowed the PHP Foundation to
host a channel on their Discord server for non-technical questions
addressed at the foundation, more specifically at Elizabeth and the
board.

You can join the server via https://phpc.chat/ and find the
#the-php-foundation channel in the "community" section.

Announcement: https://phpc.social/@thephpf/116330924522419959

Cheers
Ilija

VCS Account Request: iliaa

Sun, 26 Apr 2026 21:47:37 +0000

Thanks

Hi Ilia

Fixing bugs, adding some performance improvements and
tightening/checking security. Maybe some new features in the future.

I would also like to modernize/maintain some of my old PECL extensions
(statgrab, lchash, etc...).

Requesting VCS access for my existing iliaa@php.net account via my
GitHub iliaal account.

P.S. Couldn't use https://www.php.net/git-php.php, since already have
an account

Given your many contributions to PHP in its earlier days, your request
was approved.

Cheers

--
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

VCS Account Request: iliaa

Sun, 26 Apr 2026 21:43:26 +0000

Hi Ilia

Fixing bugs, adding some performance improvements and tightening/checking security. Maybe some new features in the future.

I would also like to modernize/maintain some of my old PECL extensions (statgrab, lchash, etc...).

Requesting VCS access for my existing iliaa@php.net account via my GitHub iliaal account.

P.S. Couldn't use https://www.php.net/git-php.php, since already have an account

Given your many contributions to PHP in its earlier days, your request
was approved.

Cheers

[RFC] Remove the links to X.com from PHP.net

Sun, 26 Apr 2026 17:59:01 +0000

Any response about reasonable alternative RFC?
https://gist.github.com/pronskiy/995feaf238cd7ae33c7d2461cd929d70

[RFC] Remove the links to X.com from PHP.net

Sun, 26 Apr 2026 17:17:24 +0000

Hi,

I intend to start the vote on this RFC next Saturday, May 2nd.

Thanks.

Jim

[RFC] Polling API

Sat, 25 Apr 2026 22:04:33 +0000

Hi

Am 2026-03-31 15:23, schrieb Jakub Zelenka:

There is actually no internal API for hooks so it would require using
object handlers (which is from the user space point of view just
__get). It
means no stubs declaration either. We also don't have an internal
policy
where to use hooks and where methods. So there are still lots of
blockers
to start using it in core.

While I agree with the conclusion that using hooks internally is
complicated and there is no real policy there, Valentin was actually
making a good point: We could use regular readonly properties for
those cases where we're just exposing a “constructor parameter”.
Specifically:

Context::getBackend() -> public readonly Backend $backend;

Watcher::getHandle() -> public readonly Handle $handle;

Potentially Watcher::$data could also be a regular (non-readonly)
property, or does modifyData() contain additional logic that is not
just “store the value somewhere”?

I tried to convert few but it resulted in quite ugly inconsistent mess.
Some of those need back calls to backend so they are really not ideal for
this. So I will stick with the current getters as the API is a bit nicer
with them IMO.

Kind regards,

Jakub

[RFC] Polling API

Sat, 25 Apr 2026 21:58:30 +0000

Hi,

Hi,

Hi

Sorry for the late feedback, it's hard juggling all the different RFCs
that are in progress to provide meaningful feedback.

Am 2026-03-11 22:07, schrieb Jakub Zelenka:

I also think that there is not really much use case for user space to
implement their own handles so such interface would be used only
internally
anyway.

This applies equally to interfaces and abstract methods. The abstract
base class however will make it much weirder when a specific (future)
handle might need to implement additional interfaces or abstract
classes.

In addition interface would effectively expose the internal stream fd
which
is currently hidden and makes harder messing up with stream fd which
might
cause various issues.

I don't understand that point. For both an interface and an abstract
method, the method would exist on the child class and thus can be
called
by a developer.

Well if it is abstract, then the method can be protected and because
the
classes are final, user spaces cannot call it. But for interface I
would

Protected methods of internal classes should still be accessible to
Reflection.

Good point.

need to make it public which means that StreamHandle would need to
expose
callabable (public) method. I know that I could just return 0 and use
different handling internally but I think this would be surprising and
created obvious inconsistency. I mean it's fine if the calls happen
internally but if the exposed methods are just dummy and return
nonsense
for user space, then I don't think it would be a good design.

It's equally weird that there is a protected method that is effectively
internally called by an unrelated class (Context) that is not supposed
to know about it. Perhaps the correct solution would then be removing
the getFileDescriptor() method from the public API entirely and change
Handle to be an empty “marker interface” that cannot be implemented in
userland (similarly to Throwable) to leave all options open for the
future?

This (marker interface just for internal classes) is actually a really
good idea. Will change it.

I just implemented this and it's much better so thanks for this. RFC
updated as well.

[RFC] [Discussion] array_get and array_has functions

Sat, 25 Apr 2026 19:37:02 +0000

Tim,

Many thanks for your comments regarding the RFC, I have updated it.
Regarding the issue of throwing errors if a path cannot be traversed due to
an intermediate step not being an array, I tend to agree with Larry so I am
leaving this as it is for the time being

Cheers

Carlos

Hi

Am 2026-04-20 17:18, schrieb Larry Garfield:

Just to make sure we're talking about the same thing here. Tim, you're
suggesting that this:

$a = ['foo' => 'bar'];
$val = array_path_get($a, ['foo', 'bar', 'baz']);

Should error rather than returning null?

Yes.

If the array were clearly, consistently, and properly structured, we
could reliably just do $a['foo']['bar'] and move on with life.
[…]
So in that sort of case, I'm not sure it's useful to distinguish
between "There is no baz key on the array at foo.bar" and "foo.bar is a
string, not an array, wat?" […]

The goal of the RFC is replacing $a['foo']['bar'] where the path is
dynamic. Quoting right from the introduction of the RFC:

When the structure of the array is known in advance and the exact
element to retrieve is hardcoded, existing PHP syntax works well […]

And quoting further from the introduction:

array_path_get() retrieves a value from a deeply nested array and
returns a default value if the path does not exist.

I'm arguing that a “(value at) path does not exist” is something
fundamentally different from “value encountered on path cannot be
traversed further”.

converting to an object

I agree that the correct solution in the general case is “use a proper
object mapper” (such as Valinor) and don't see much personal value in
having the proposed functions. But if they exist, I would want them to
behave as safely as possible and that includes erroring if they cannot
make sense of the data. Emitting a Warning when encountering an
improperly typed value across the path would also work for me, but I
suppose that others won't be in favor of that :-)

Best regards
Tim Düsterhus

VCS Account Request: iliaa

Sat, 25 Apr 2026 14:30:33 +0000

Fixing bugs, adding some performance improvements and tightening/checking
security. Maybe some new features in the future.

I would also like to modernize/maintain some of my old PECL extensions
(statgrab, lchash, etc...).

Requesting VCS access for my existing iliaa@php.net account via my GitHub
iliaal account.

P.S. Couldn't use https://www.php.net/git-php.php, since already have an
account

--
Ilia Alshanetsky
E: ilia@ilia.ws

Hi,

I don't think you need VCS access for these actions. You can just submit a
PR with your changes.

VCS Account Request: iliaa

Sat, 25 Apr 2026 12:56:57 +0000

Fixing bugs, adding some performance improvements and tightening/checking
security. Maybe some new features in the future.

I would also like to modernize/maintain some of my old PECL extensions
(statgrab, lchash, etc...).

Requesting VCS access for my existing iliaa@php.net account via my GitHub
iliaal account.

P.S. Couldn't use https://www.php.net/git-php.php, since already have an
account

--
Ilia Alshanetsky
E: ilia@ilia.ws

[RFC] Deprecate Metaphone Function

Sat, 25 Apr 2026 10:33:22 +0000

Hi internals,

Currently, PHP core maintains the oldest and least accurate version of the metaphone algorithm in C in the metaphone function. It was superseded by more accurate algorithms, namely Double Metaphone and Metaphone 3, and only limited to English pronunciation rules. There are already robust and actively maintained userland libraries available via Composer that implement Double Metaphone and Metaphone 3 1 3.

I therefore would like to introduce a RFC to deprecate the metaphone function. Maintaining this legacy function in the core provides little value to modern PHP applications, and users could be advised to switch to more accurate alternatives. Even in the case where strict backward compatibility with core functions is preferred, people can still use soundex instead.

RFC link: https://wiki.php.net/rfc/deprecate-metaphone

I am happy to know your thoughts on this.

— Weilin Du <1372449351@qq.com, lamentxu@163.com>

[VOTE] Oniguruma maintenance end and end of mbregex

Sat, 25 Apr 2026 00:32:40 +0000

2026年4月11日(土) 13:09 youkidearitai youkidearitai@gmail.com:

2026年4月10日(金) 14:42 Matteo Beccati php@beccati.com:

Hi,

Il 10/04/2026 02:41, youkidearitai ha scritto:

Hi, Internals

I started voting for "Deprecate mbregex 8.6 and delete 9.0".
https://wiki.php.net/rfc/eol-oniguruma

Thanks for your clarifications: I'm in favour of the proposal.

The deprecation message might require some tweaking to better fit the
English grammar, but that's just a minor thing ;-)

Cheers

Matteo

Hi, Matteo
Thank you for your feedback.

Indeed, We need to change the description message.
Change that message if this voting is accepted.

Regards
Yuya

--

Yuya Hamada (tekimen)

https://tekitoh-memdhoi.info

https://github.com/youkidearitai

Hi, Internals
This vote is ended. 24 yes, 0 no, 0 abstain.
This RFC is accepted.

Thank you very much for voting.

Regards
Yuya

--

Yuya Hamada (tekimen)

[RFC] Secure Session Configuration Defaults

Fri, 24 Apr 2026 07:40:38 +0000

Thanks Gina for input. I see it as an improvement as well and would be
happy to help with it. However, I like to keep things separated in this RFC.

If no new comments will arrive I would like to move to voting phase next
week.

Kind regards,
Jorg

PHP 8.5.6RC1 available for testing

Fri, 24 Apr 2026 00:09:21 +0000

PHP 8.5.6RC1 has just been released and may be downloaded from
https://downloads.php.net/~daniels/

Or use the git tag: php-8.5.6RC1

Windows binaries are available at:
https://www.php.net/pre-release-builds.php#windows

Please test it carefully, and report any bugs at
https://github.com/php/php-src/issues

8.5.6 should be expected in 2 weeks, i.e. on the 7 May 2026.

Hash values and PGP signatures can be found below or at
https://gist.github.com/DanielEScherzer/108510dd1016e1c63946309e0dd245d9

Thank you, and happy testing!

Regards,
Daniel Scherzer, Volker Dusch, and Pierrick Charron

php-8.5.6RC1.tar.bz2
SHA256 hash:
c1dc3dfc7be00aff78e92419b990cc99a447a338be213a3c542030bd08dd717a
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmnn7KUACgkQdORLyQZ3
AaULhw//VU3E0Jq7uWU81ZQnqmRozaxtKfvFntCyuXqxknXFK3oZc1adwGeNhulF
hMABZ5KqAko1yNi2pcJ/4KC+GVkGPWXwUrzr6/rT+99bwtfExpt1LG5WYDtg8pGV
zmZ7+Ud85MxCzk/5QlGdpZJmyWDX/pV6haI12tOI/ZI8QQQuAHtopOB2ew+raGnH
A7p/qNHfAUGb39d5JXGlKzeBc3mJLLwl4rEg6UoxS0QTphUTgtXimcR0hDIsbbOu
kXWLOQA3pUWXJF3nohYJa+6iHV3ZpyCVxj7KfJmIpAfHD6J9XcC6OgLs2+Ne/WLJ
EUv3+vPMSUHEcBnsFITdCs0A+SElGm+1E5/YkId8KvD2rDDPstO/+OikgHx7MTxQ
0suurrfior318zY4jjHgxCO0iEtNEcHhN+7GASQ+b1jv0+xv4qOmEpBISIXbzRZ7
eZOifeOQo7Mq/lWkqngnzLNjHgk85TR3oLN+6MpDVWcly5qQS6eQ51YRbE+Ma6CH
fcCzLTbcIpuUC2E4D/r5/n2Vd0rYpIS9436ljH4+J9ogK0+AmZb0i7xKvqqwP8ko
0utXw8nAAmHERhJQqltDpd8FY3I3wp7VmOjyfq1ldVQ9RBID0XF3XrIAsYYOzV8Z
ChvemxTW15jjKZCSOuXT/L6kNtqf3eGQHBiHoPMYU0vuERv9VEo=
=+qHF
-----END PGP SIGNATURE-----

php-8.5.6RC1.tar.gz
SHA256 hash:
dc1cf05cd4533b81506074c208db1ce33b643ce30108392233cae21a5c841734
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmnn7K0ACgkQdORLyQZ3
AaVHORAAv3meqz6caNiO87R6QyX/q014Ulnce7q5fpKMKuSERXi+c0nISm7XFFbO
F/lNBJDilV/zpjV4dumzrhV7Z6JTq0CUovVjzZxYfLsHGv9m9J1J0cfo21j1q+Gz
x7xbl+E4ja0CQxJNZxUKKBzEjOLipFkGHhXresQamJzebRmJTL2VtYOjrTyynJ+v
i8nYEg+2+1AUzjg3uELYt5faaxohfsC3P8zceJ4vADV9MIK+pTn/zN+woD6RC9kU
2T/MFByekKZm+PJ+zC+O0tQoS22JeCEA/Yu6gwtb8vs1mer1Dj2PiCTYB1vmeyEN
wYDyXb+XDu6YrUZfTYUqbYfCuQew1Bzv3yztGyP4m3aESw09/bnJTLahQLd3MeZA
MmDlfbn+H/huzvLzSxxruBSjrRxJ8zO9O9QISgVOJHS67ZpqZdwWzif1ynaGXHWd
DvrfW0kj2YAjfRK6FqInPUqaM8djVjXgA9YaN2CVx2lSaacpJ1ZfkLwK+IA188xA
agNv8xIyY4KX9HmxmZaDRYdewCjVNrUgvcuuHNDbVXt1BNDg1laZUCzsFLOH8UhS
dfJc5eG/YrBaomoun4bHOYKyQZwpcaqd9kiFzbBwj4eqXe2aht64bAs4mlB/3+vX
FHiQj5PxST04mopmFszEP5DDggnoY548o9iTNIuxr4VykLTFtZw=
=Z664
-----END PGP SIGNATURE-----

php-8.5.6RC1.tar.xz
SHA256 hash:
d57fa52541f8f2dd9511efb42e2b9307af49189a64f07cb69ae078371f70b4dc
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE2VwDvHAr6VFTRK4zdORLyQZ3AaUFAmnn7K0ACgkQdORLyQZ3
AaUYLA//TJtl4E82Uq6rUtpSDUqKXNdmjP2TrGXG4yXbJnVUaR5H0tgOAh5iH05W
h5wl9Uiwdy0mzzkRsSZ23sa4WSYNrTj1Kcw5MANR2Pb8qxCAPWURHMsIcmdJdyk1
Fs4XhJDRxgLa/nCLWChB+vBy8hv0DKk21LrOo/fqSeyr0KeFNujFrbt9EjfgU6Hx
YdEorMZ3R13gCmZFqrsMw62PKdnypVvVeS9thPzuhrDXZud4LsfOdkDU7xDBP29U
FMo79/l06SFq2gbNBfXORJWcWoIskTV+veugmhU14fzE3sK8YUDrxU/SUv92PYDx
Uuez6+3KcHO0B8ZHbmMNzPUBVjbJjrrEP2hZ4KjXPJMjORcSziqHQUezZTdI+UpI
TXfh1CWDboz9Tb8DuhZw6CKoVwFej1TUSldceMOaQScB0t46wN9UvUWkI/xj+HeW
0ghWR2wPStz0hiItQuHwKCNmM2ly3ulfe5fVf6m7lMJyvnBN3qV/f5AjvRC4x+Mw
5jtlkBSP1Kklo/KHtHoFnEik6fx6VBqC9OPdRjEJ2Cfwh2ONl43aYUF+/+JzwTLv
pYcSeBDZIvFTaHpw1YDbqMByMc5QvgLjYePyi4f58PWWl6DSsXSIZ1Ar7z75WH/w
zfB2STMWsBcqw1JsupPP8E4Bw8hDyto1zRomy08Twx+rbEsLEXg=
=xxIa
-----END PGP SIGNATURE

PHP 8.4.21RC1 Ready for testing

Thu, 23 Apr 2026 19:53:57 +0000

PHP 8.4.21RC1 has just been released and may be downloaded from
https://downloads.php.net/~calvinb/

Or use the git tag: php-8.4.21RC1

Windows binaries are available at: https://www.php.net/pre-release-builds.php#windows

Please test it carefully, and report any bugs at https://github.com/php/php-src/issues

8.4.21 should be expected in 2 weeks, i.e. on the 7th.

Hash values and PGP signatures can be found below or at
https://gist.github.com/NattyNarwhal/2bf59791bd5e09f6c7b5b98c55a84b39

Thank you, and happy testing!

Regards,
Calvin Buckley, Saki Takamachi, and Eric Mann

php-8.4.21RC1.tar.bz2
SHA256 hash: 92be1ab180946fb6fe21456cfae08190fe556fb643d56043bd56f034ae145368
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCaeehshsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwwLDMACgkQVql692AKOabB6AEA0m8SfXYY37qj0AY5Dg/q
wjHUnhrUvzh0lrcHQD7BUZMBAJSM6OecwxT+fgz50b/guz7mgnJNLOOH02p6aiVP
FZcE
=s2Y5
-----END PGP SIGNATURE-----

php-8.4.21RC1.tar.gz
SHA256 hash: e4c3eb09b3948bda0a0e41c73424a73c1d3ca6c7ee81efb22f26f07cb7476929
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCaeehshsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwwLDMACgkQVql692AKOabNggEAxisNSy/zWE1g4efIvBMn
TUrLzBvyVMUeD/jj4buwue8BAIHXC/D7Zi5i1t21D8xKLTUkyU8Uf5sTWYIXluqT
2GAO
=JyLs
-----END PGP SIGNATURE-----

php-8.4.21RC1.tar.xz
SHA256 hash: c1a77cbbfe2dc7dd37b11f88ff68f112dbed6eaa9ba2d232e0a1b57852c93096
PGP signature:
-----BEGIN PGP SIGNATURE-----

iJEEABYKADkWIQSdf5mgy48FyKaVjWJWqXr3YAo5pgUCaeehshsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwwLDMACgkQVql692AKOaatkAD9HzOE7TFKGfY+XanuEsQg
BaiRbpWgVwLhnHn0Ki1yU5gA/08S7dv8iNELqx+6ff/vUs5f9kh0fGPMPojJmTtJ
CZQO
=n3/7
-----END PGP SIGNATURE

wiki maintenance

Thu, 23 Apr 2026 13:54:49 +0000

TLDR: wiki.php.net will be down for maintenance for about 15 minutes
commencing Thursday April 23rd, 2026, from 13:00 UTC onwards.

This has now been completed.

If you encounter any problem afterwards, please file a ticket at https://github.com/php/infrastructure/issues using the "property: wiki" label.

cheers,
Derick

[RFC] Context Managers

Wed, 22 Apr 2026 18:28:15 +0000

I will say it is weird to have exitContext return an exception; but what happens if an exception is thrown during exitContext? Why not just have it return void and throw if you need to throw instead of having two paths to the same thing?

There's a subtle but important difference here: An exception passed through exitContext() is the original exception from lower in the call stack, and its backtrace will be the original location of the error. An exception thrown from within exitContext() itself indicates a failure that the Context Manager is responsible for, usually an error in the exitContext() logic itself.

PHP collects traces when exceptions are constructed, not when they're
thrown, so this is a distinction without a difference. From the
outside, it's impossible to tell the difference between "return $e;"
and "throw $e;".

That means you have the following options:

throw the passed exception unchanged

return the passed exception, which is equivalent to throwing it

throw a new exception, or fail to catch an exception in the cleanup
logic, which as Rob points out will hide the passed exception unless
you remember to attach it as $previous

return a new exception, which according to the current RFC text will
be completely ignored (is "throw $e" supposed to say "throw $__ret"?)

It does seem like it would be more straightforward to have the return
value be "void", and leave it to the implementation to throw or not.

In practice, as you say, "throw unchanged" will be common, but unless
that's the behaviour of a null return (i.e. the default if not opted
out), "throw $e;" seems the natural boilerplate for that.

Since this seems like a contentious area, let me go back to first principles and try to explore the problem space. (This is an essay; meaning I don't know where it's going to end up yet as I write this.)

The problem space

A context manager may exit in one of two conditions: Success or Failure.

There are three types of code that a CM may want to run, but not always all of them:

Code that happens on success.
Code that happens on failure.
Code that happens on both.

In the case of Success, there is no value to propagate.

In the case of Failure, there is a value (exception) to conditionally propagate, but the default case should be propagate.

The CM may have its own error, in which case it will want to propagate that error (as a throwable).

Would a CM ever want to wrap-and-rethrow a lower-level exception, rather than just passing it on itself? I suppose it's possible, though I'm not sure of a specific example off hand.

Python's answer

The Python answer is a single __exit__ method, which may be passed optional exception information. In Python, not returning anything is equivalent to returning null, which is falsy, so "return true to stop propagation or do nothing to continue propagation" is reasonable and ergonomic. That is not the case in PHP, however; a function with a typed return MUST have a return statement in it, and it's not immediately obvious to a user what true-vs-false will do. (Does true mean "yes propagate" or "yes suppress"?) It also makes the return value meaningless in the success case, which is not immediately obvious. So mimicking Pythong in this case is not a viable approach.

Basic structure

In PHP, we could have the three different code paths in one, two, or three methods.

The three method approach would be something like:

public function contextSuccess() {
  // Do stuff only on a success case.
}

public function contextFail(Throwable $e): bool {
  // Do stuff only on a failure case, you must return a value.
}

public function contextExit() {
  // Do stuff in any case.
}

That approach has 2 problems: One, contextExit() must then be called either before or after the success/fail callback, always, which may not support the desired cleanup process. Two, if all three are on the CM interface then they all must be implemented, even if there's nothing for them to do. That's bad ergonomics. (Side note: interface-default-methods would help a ton here.)

The second point could be resolved by making them all magic methods rather than an interface, but that brings with it all the lack-of-introspection challenges of magic methods.

The two method approach would be:

public function contextSuccess() {
  // Do stuff only on a success case.
  // Do common stuff here.
}

public function contextFail(Throwable $e): bool {
  // Do stuff only on a failure case, you must return a value.
  // Do common stuff here, redundantly.
}

Or alternatively, call out to a separate common method from both. This would probably work, but again has two problems: One, it makes common actions harder to do, as it requires either redundancy or another method (which may not always be viable in context). Two, the same "must define both of them even if you don't care" problem exists. (Again, interface-default-methods would solve this.)

The single method approach is what the RFC currently proposes:

public function contextExit(?Throwable $e) {
  // Do whatever you want, in whatever order, and if ($e === null) to differentiate success/failure.
}

This approach resolves both issues of the previous models, but creates one more: the exit condition (return, throw, etc.) from this method is quite complex:

In a Success case, there is no exit condition (return and continue)
In a Failure case, there is a binary exit condition (propagate or suppress)
In the case contextExit() itself has a failure, it would need to throw its own exception, which implies suppressing the original.

I do believe the single-method approach is the least-bad, if we can resolve the exit condition question.

Ways of handling a single method's returns

Possible ways to do so off the top of my head, in no particular order:

Return True to suppress, return False to propagate, return Null on success, throw on CM error. (This is what earlier versions of the RFC had.)

Pro: Clear delineation for each pathway.
Con: Needlessly complex in practice and not self-documenting. Doesn't differentiate between CM exception and underlying exception.

public function exitContext(?Throwable $e): ?bool {
  if ($e) { 
    // Error cleanup
  } else {
    // Success cleanup
  }

  // Oops, something went wrong.
  throw CMException();

  // Common cleanup

  return $e === null;
}

Same as previous, but use enums.

Pro: more self-documenting.
Con: Still needlessly complex, now more verbose, too! Doesn't differentiate between CM exceptions and underlying exceptions. Returning one of the Failure case values on a Success case would, uh, just ignore it? That's not great.

public function exitContext(?Throwable $e): ?bool {
  if ($e) { 
    // Error cleanup
  } else {
    // Success cleanup
  }

  // Oops, something went wrong.
  throw CMException();

  // Common cleanup

  if ($e) { 
   if (something) {
      return CMResult::Propagate;
    }
    return CMResult::Suppress;
  } else {
    return CMResult::Success;
  }
}

Return an exception to cause it to throw, or null to not throw. This folds the return value into a single line in most cases. (This is what the RFC says right now.)

Pro: Ergonomically very convenient.
Con: return $e and throw $e become effectively the same thing, so it's not clear when you'd use one or the other. Doesn't differentiate between CM exception and underlying exception.

public function exitContext(?Throwable $e): ?Throwable {
  if ($e) { 
    // Error cleanup
  } else {
    // Success cleanup
  }

  // Oops, something went wrong.
  throw CMException();

  // Common cleanup

   return $e;
}

As Rowan suggested, void return, only propagate on throw.

Pro: Folds different pathways together in a natural way.
Con: The most common case (propagate exception) is the one that requires additional work, not the rare case (not propagating), so I can see it being very common for people to forget to rethrow. Doesn't differentiate between CM exception and underlying exception.

public function exitContext(?Throwable $e): void {
  if ($e) { 
    // Error cleanup
    throw $e;
  } else {
    // Success cleanup
  }

  // Oops, something went wrong.
  throw CMException();

  // Common cleanup
}

Follow event-dispatcher patterns, like PSR-14, and call a built-in method to prevent propagation.

Pro: In the typical case where you want to allow propagation, there's literally nothing to do. That makes the common case very ergonomic.
Con: This would necessitate either a ContextManager base class instead of interface, or some black magic where adding the interface magically adds this method. (Side note: interface-default-methods would probably help here.)

public function exitContext(?Throwable $e): void {
  if ($e) { 
    // Error cleanup
    throw $e;
  } else {
    // Success cleanup
  }

  // Oops, something went wrong.
  throw CMException();

  // Common cleanup

  // $e will get propagated unless this is called.
  $this->stopPropagation();
}

Totally wild thought: throw a special "don't throw anything else" exception, which gets special handling.

Pro: In the typical case where you want to allow propagation, there's literally nothing to do. That makes the common case very ergonomic.
Con: Throwing an exception to prevent an exception from being thrown is just... weird.

public function exitContext(?Throwable $e): void {
  if ($e) { 
    // Error cleanup
  } else {
    // Success cleanup
  }

  // Oops, something went wrong.
  throw CMException();

  // Common cleanup
  
  // If this line is missing, $e gets rethrown.
  throw new StopPropagationException();
}

None of these allow differentiating at runtime between a CM error and an underlying error. In most it could be differentiated in static analysis, but not at runtime. Whether or not that is a problem is, I think, an open question.

The Python PEP for context managers suggests that if one cares, it's possible to avoid using and call it manually, allowing for that differentiation. If we use the return $e approach, a manual/higher-order CM could make the differentiation by calling the CM methods itself, rather than relying on using.

try {
  $cm = new SomeCM();
  $cv = $cm->enterContext();
  
  // Do code here.
  
  $e = $cm->exitContext($e);
  if ($e !== null) {
      // body failed, exit success
  }
} catch (\Throwable $e) {
  // body failed, exit failed too
}

However, the whole point of using blocks is to not need to do that, so if it's a common need, that would be highly sub-optimal. It also wouldn't be available in the other approaches.

Conclusion

I think a key question to answer here is: Do we care to differentiate between CM errors and underlying errors? If not being able to do so is a non-issue, or small enough that we don't care, then we have more options. I'm not sure which of the last 3 I like most/dislike least: "always rethrow", "call method to suppress", "throw special to suppress". They all have pros and cons.

If we do care, then we may need to adapt the materialized code and expand the syntax in some way to allow for it. I'm not sure yet what that would look like.

I will stop here, however, and ask for input from the audience. (Not just the regulars in this thread of late, but all of you reading this.) Including if you have an alternate approach to the three listed above that would have notably fewer cons.

--Larry Garfield

wiki maintenance

Wed, 22 Apr 2026 16:26:55 +0000

Hi,

TLDR: wiki.php.net will be down for maintenance for about 15 minutes
commencing Thursday April 23rd, 2026, from 13:00 UTC onwards.

Long form:

We're upgrading all our machines to a newer Debian (13), which will also
have the benefit of having PHP 8.4 installed. Instead of upgrading
existing machines, we are republishing each website property on a new
VM, and this requires:

stopping the web server on the old machine
running a back up of the data (As things might have changed since the
nightly backup run)
restoring the backup on the new machine
switching DNS to the new machine, and wait

As an experiment, at the same time we are also switching to a different
CDN provider for the wiki. This will not give any extra down time, and
if it doesn't work out, changing back to our existing provider will not
cause any downtime either, as the origin server won't be changing at the
same time.

I will send an email here when the DNS switch has been accomplished, but
it then might take some time with some ISPs for them to refresh their
own caches.

If you encounter any problem afterwards, please file a ticket at
https://github.com/php/infrastructure/issues using the "property: wiki"
label.

cheers,
Derick

[VOTE] SNMP extension improvements

Wed, 22 Apr 2026 12:22:50 +0000

Il 21/04/2026 14:15, Steven Wilton ha scritto:

Hi,

I have started voting for the "SNMP Improvements" RFC

https://wiki.php.net/rfc/snmp_improvements_2026

The voting end is 2026-05-08 00:00:00 UTC

I didn't get any responses to my post regarding discussion of this
RFC, but I'm hoping that the code is straightforward enough that
people can vote on it.

I think there's a problem with the voting widget.

Cheers

I've just changed the closedon/closed flags on the votes. Is it working
now?

[RFC] Partial Function Application: Handling of Optional Parameters

Tue, 21 Apr 2026 17:52:06 +0000

as part of the design for a “PFA for $this” RFC, Arnaud and I came
across one issue in the original design of PFA that makes it hard to do
the “PFA for $this” follow-up in a way that does not violate user
expectations. Specifically the handling of “optional parameters”. With
the support of Larry as one of the original authors of the PFA RFC, we
would like to propose an amendment to the PFA RFC that is unlikely to
affect real-world use-cases, but that will enable these follow-ups and
that will result in a more predictable behavior overall.

Please find all details in the RFC at:
https://wiki.php.net/rfc/partial_function_application_optional_placeholder

Unless significant discussion happens, I expect the RFC to go to vote in
2 weeks, so that it can be incorporated in the PFA implementation right
away.

Best regards
Tim Düsterhus

[VOTE] SNMP extension improvements

Tue, 21 Apr 2026 12:37:36 +0000

Hi,

Il 21/04/2026 14:15, Steven Wilton ha scritto:

Hi,

I have started voting for the "SNMP Improvements" RFC

https://wiki.php.net/rfc/snmp_improvements_2026

The voting end is 2026-05-08 00:00:00 UTC

I didn't get any responses to my post regarding discussion of this RFC,
but I'm hoping that the code is straightforward enough that people can
vote on it.

I think there's a problem with the voting widget.

Cheers

Matteo

[RFC] Context Managers

Tue, 21 Apr 2026 12:16:22 +0000

I will say it is weird to have exitContext return an exception; but what happens if an exception is thrown during exitContext? Why not just have it return void and throw if you need to throw instead of having two paths to the same thing?

There's a subtle but important difference here: An exception passed through exitContext() is the original exception from lower in the call stack, and its backtrace will be the original location of the error. An exception thrown from within exitContext() itself indicates a failure that the Context Manager is responsible for, usually an error in the exitContext() logic itself.

PHP collects traces when exceptions are constructed, not when they're thrown, so this is a distinction without a difference. From the outside, it's impossible to tell the difference between "return $e;" and "throw $e;".

That means you have the following options:

throw the passed exception unchanged
return the passed exception, which is equivalent to throwing it
throw a new exception, or fail to catch an exception in the cleanup logic, which as Rob points out will hide the passed exception unless you remember to attach it as $previous
return a new exception, which according to the current RFC text will be completely ignored (is "throw $e" supposed to say "throw $__ret"?)

It does seem like it would be more straightforward to have the return value be "void", and leave it to the implementation to throw or not.

In practice, as you say, "throw unchanged" will be common, but unless that's the behaviour of a null return (i.e. the default if not opted out), "throw $e;" seems the natural boilerplate for that.

Regards,

Rowan Tommins
[IMSoP]

[VOTE] SNMP extension improvements

Tue, 21 Apr 2026 12:15:47 +0000

Hi,

I have started voting for the "SNMP Improvements" RFC

https://wiki.php.net/rfc/snmp_improvements_2026

The voting end is 2026-05-08 00:00:00 UTC

I didn't get any responses to my post regarding discussion of this RFC,
but I'm hoping that the code is straightforward enough that people can
vote on it.

regards

Steve

DocComments for internal functions

Tue, 21 Apr 2026 09:33:41 +0000

Am 10.04.2026 um 23:47 schrieb Christian Schneider cschneid@cschneid.com:

Am 10.04.2026 um 17:40 schrieb Derick Rethans derick@php.net:

Am 10.04.2026 um 12:54 schrieb Gina P. Banyard internals@gpb.moe:

The implementation can be examined at
https://github.com/php/php-src/compare/master...chschneider:php-src:internal-functions-doccomments

I am not fully convinced that we should add DocComments for internal parameters/functions/classes/constants, as this feels like a lot of complexity.

What kind of complexity are you thinking about? Code-wise? Integration into the build process?

I'm wondering how much this does to increase the size of the PHP compiled binaries.

On my machine it adds about 2M (7%) as the sapi/cli/php binary increases from ~28M to ~30M for a build with default ./configure and
CFLAGS="-O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"

I would assume this is mostly in a read-only data section and hence shareable between processes.

I checked again for more extensions (end hence more doc comments) enabled and surprisingly the difference was not as big as I first reported.

Here are the configure options I used:
CFLAGS='-O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
CXXFLAGS='-O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
CPPFLAGS='-O3 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
'./configure'
'--enable-bcmath'
'--enable-debug=no'
'--enable-exif'
'--enable-intl'
'--enable-pcntl'
'--enable-soap'
'--with-zip'
'--enable-mbstring'
'--with-curl'
'--with-freetype'
'--enable-gd'
'--with-gettext'
'--with-iconv'
'--with-jpeg'
'--with-webp'
'--with-ldap'
'--with-mysqli'
'--with-openssl'
'--with-pear'
'--with-pgsql'
'--with-pdo-mysql'
'--with-zlib' \

Result:

a) No file size difference!? Not 100% what that means:

$ ls -l php.{master,doccomments}
-rwxrwxr-x 1 cschneid trusted 32287008 Apr 21 10:55 php.doccomments
-rwxrwxr-x 1 cschneid trusted 32287008 Apr 21 10:55 php.master

b) About 500k difference in the .rodata segment:

$ diff -u <(eu-size -d -A php.master) <(eu-size -d -A php.doccomments)

-php.master:
+php.doccomments:
-.text 8629549 6322432
+.text 8629293 6322432
-.rodata 14933412 18874368
+.rodata 15459140 18874368
-.eh_frame_hdr 163060 33807780
+.eh_frame_hdr 163052 34333508
-.eh_frame 955472 33970840
+.eh_frame 955424 34496560
-Total 26223763
+Total 26749179

============

Now so far I got no input in how to proceed: Should I create an RFC or directly a PR?

I see the following possible outcomes:

The whole idea is rejected by the maintainers / community
The foundation to generate PHP binaries with doc comments for internal functions is added and documented but not enabled
In addition to 2) before each release the doc comments are generated / updated from the current doc-en repository (and committed?)

Adding doc comments to the source currently requires calling
./build/add_doccomments.php && ./build/gen_stub.php --force

The current implementation can be examined at
https://github.com/php/php-src/compare/master...chschneider:php-src:internal-func-doccomments

I'd appreciate any thoughts,

Chris

[RFC] Context Managers

Mon, 20 Apr 2026 20:09:36 +0000

Am 2026-04-15 16:52, schrieb Larry Garfield:

The finally path is only reached in case of a successful exit.
Therefore there is no exception to pass in, and thus returning an
exception is meaningless. […]

That's not at all how I understood the RFC text (and I admittedly didn't
look at the desugaring):

If exitContext() returns a throwable (either a new one or the one it
was passed), it will be rethrown.

I understood the “it” in “it will be rethrown” as “the returned
Throwable is thrown”, not “the Throwable that was caught is thrown”.
That is also what is mentioned in your email
https://news-web.php.net/php.internals/130413:

or a throwable, which will then get thrown

and

If there's a reason to wrap and rethrow the exception, do that and
return the new exception

And that is what the second half of my email
https://news-web.php.net/php.internals/130479 is based on, particularly
the joke in the footnote. Why has this misunderstanding not been pointed
out back then?

So based on the desugaring that Rob thankfully looked at, of all the
information in a ?\Throwable return type, only a single bit is used -
and only in some cases. I don't see how we can meaningfully explain to
users that throwing away all the other information is the expected behavior.

Best regards
Tim Düsterhus

[RFC] [Discussion] array_get and array_has functions

Mon, 20 Apr 2026 17:04:55 +0000

Am 2026-04-20 17:18, schrieb Larry Garfield:

Just to make sure we're talking about the same thing here. Tim, you're
suggesting that this:

$a = ['foo' => 'bar'];
$val = array_path_get($a, ['foo', 'bar', 'baz']);

Should error rather than returning null?

Yes.

If the array were clearly, consistently, and properly structured, we
could reliably just do $a['foo']['bar'] and move on with life.
[…]
So in that sort of case, I'm not sure it's useful to distinguish
between "There is no baz key on the array at foo.bar" and "foo.bar is a
string, not an array, wat?" […]

The goal of the RFC is replacing $a['foo']['bar'] where the path is
dynamic. Quoting right from the introduction of the RFC:

When the structure of the array is known in advance and the exact
element to retrieve is hardcoded, existing PHP syntax works well […]

And quoting further from the introduction:

array_path_get() retrieves a value from a deeply nested array and
returns a default value if the path does not exist.

I'm arguing that a “(value at) path does not exist” is something
fundamentally different from “value encountered on path cannot be
traversed further”.

converting to an object

I agree that the correct solution in the general case is “use a proper
object mapper” (such as Valinor) and don't see much personal value in
having the proposed functions. But if they exist, I would want them to
behave as safely as possible and that includes erroring if they cannot
make sense of the data. Emitting a Warning when encountering an
improperly typed value across the path would also work for me, but I
suppose that others won't be in favor of that :-)

Best regards
Tim Düsterhus

PHP Manual: Including phpc.tv PeerTube on the Tutorial What's Next page

Mon, 20 Apr 2026 15:20:42 +0000

Hi all,

I've proposed an update to the "What's Next" section of the Tutorial in
the PHP Documentation which includes, among other resources, a link to
https://phpc.tv - a community run PeerTube video site.

It's been raised that this should perhaps be discussed on internals
before inclusion.

PR: https://github.com/php/doc-en/pull/5491

I think it's particularly valuable in this section of the manual because
it fulfills multiple purposes:

Content includes video tutorials, for those who prefer them

Showcases a variety of current tools, frameworks and libraries

Advertises podcasts people can follow

Conference talks (in this regard it effectively replaces talks.php.net
on this page, which hasn't had any new talks uploaded in recent years,
and only includes the slides)

The PHP site and manual is already including links to wider community
content, such as Composer / Packagist, and various community run sites /
Discords on the "Help" page.

It's run by prominent community members (under the PHPC Collective[0]
who also run the phpc.social Mastodon ) and I know that Anna Filina
specifically is one of the people working directly on it[1].

Given who runs it, I consider it a safe resource that's likely to show
up-to-date content for a significant amount of time.

Does anyone feel https://phpc.tv should not be included in the official
documentation here? Other thoughts?

(Any further suggestions for the revised What's Next page are welcome too)

[0] https://opencollective.com/phpcommunity/projects/phpc-social
[1] https://afilina.com/why-phpc-tv

This makes sense to me, and I support linking to phpc.tv. Perhaps as a v2, the Foundation could create an account on there and create curated playlists of already existing content that can be linked to? (And those playlists can be easily updated over time as the language changes and different things become relevant or out of date.)

--Larry Garfield

[RFC] [Discussion] array_get and array_has functions

Mon, 20 Apr 2026 15:18:16 +0000

Hi

Am 2026-04-18 08:06, schrieb Barel:

I am still unconvinced about this. Your proposal seems to give the
null
a special value and I think that in general the full semantics are less

null being a value indicating absence is by no means “special” in my
suggestion. As previously mentioned, it's the semantics of isset().
It's also what array_find() and array_find_key() return. It has
special syntax in types with the questionmark in ?Type. It's what you
get when you read a non-existent value.

clear. And I don't really like the function throwing errors for paths,
I
think that this function is great for defensive access to values, where
you
can be sure that you don't need to be checking the path all the time.
The

Defensive access to me also implies throwing errors where appropriate,
namely trying to perform an operation that is not meaningful. Trying to
access an array offset on a string is not meaningful and trying to do
something is not likely what the user intended to do. Similarly users
passing in ArrayAccess objects might reasonably expect them to “just
work”. Returning a default value instead of a clear error will likely
lead to them thinking they found a bug in PHP.

Just to make sure we're talking about the same thing here. Tim, you're suggesting that this:

$a = ['foo' => 'bar'];
$val = array_path_get($a, ['foo', 'bar', 'baz']);

Should error rather than returning null?

If so, then I do not agree. The purpose of these functions, as I see it, is for dealing with inconsistently structured, wonky, arguably stupidly-designed data. (Which is a lot of REST APIs in the wild, sadly.) If the array were clearly, consistently, and properly structured, we could reliably just do $a['foo']['bar'] and move on with life. Or trivially convert it to a properly typed object. These functions are for cases where those are not viable or convenient options, meaning cases where a given value could be a string or an array, because the data model author hates you. (As noted in a previous reply, I have run into such structures where the value of a JSON key is string|string{}. It bloody well sucks.)

So in that sort of case, I'm not sure it's useful to distinguish between "There is no baz key on the array at foo.bar" and "foo.bar is a string, not an array, wat?" If that was a distinction that mattered, I'd be using ?? or converting to an object or whatever else already.

--Larry Garfield

PQC readiness beyond OpenSSL/sodium

Mon, 20 Apr 2026 13:47:06 +0000

Hi!

I recently read Paragon Initiative's post "Post-Quantum Cryptography for
the PHP Community" [1] and have been following the broader PQC
discussions, particularly Google's and Cloudflare's migration timelines,
which seem to be pulling the industry's expectations forward quite a bit.

I want to stress upfront: I am not a security expert, and this question
may be naive. I'm asking to understand whether there's anything that needs
to be done on the language/runtime side.

My working assumption has been that the heavy lifting for PQC in PHP will
come through the libraries that ext/openssl and ext/sodium wrap, in other
words, that once OpenSSL ships stable ML-KEM / ML-DSA / hybrid primitives
and libsodium follows suit, exposing them in PHP is largely a matter of
binding new functions and constants, similar to how past algorithms were
added. Paragon's ext-pqcrypto and pqcrypto_compat seem to cover the gap in
the meantime.

What I'm less sure about is whether there are PHP-specific concerns beyond
"wait for the libraries." A few things I've wondered about, though I may
be framing them wrong:

Whether the substantially larger key/signature/ciphertext sizes of PQC
algorithms interact badly with any internal assumptions in PHP (string
handling is presumably fine, but things like stream buffer defaults,
TLS-related INI defaults, or session serialization come to mind).
Whether anything in the bundled extensions that does its own crypto
(PHAR signatures, password_hash, openssl_* wrappers, PHP's own TLS stream
context options) will need design-level decisions rather than just new
constants — e.g., how hybrid KEMs get surfaced in stream contexts, or
whether PHAR will gain PQ signature support.
Whether there's an expectation that PHP tracks a minimum OpenSSL version
that supports PQC by some date, and what that might mean for distros.
Whether any of this warrants an RFC-level discussion now rather than
closer to 2029.

Is any of the above already being tracked or discussed? Are there concerns
I'm missing entirely? I'd rather ask a possibly-dumb question now than
find out in 2028 that something obvious was overlooked. :-)

Thanks for your time,
Sebastian

--
Sebastian Bergmann https://phpunit.expert

Stay up to date with PHPUnit: https://phpunit.expert/newsletter

[IDEA for RFC] class_uses and optionally returning traits for parent classes

Mon, 20 Apr 2026 11:54:29 +0000

I think that class_uses() should never have been implemented, because
it gives a false sense of symmetry with class_implements() and
class_parents(). Implemented interfaces and parent classes can be used
as types on the corresponding object (and types are inherited), while
used traits cannot. Those are fundamentally different concepts.

I agree

If, for some reason, you want to “cheat” and use traits as if they were
inherited types, you are free to do that, but I don’t think that PHP
should provide a built-in function that goes beyond what traits are
intended for.
That won't even work reliably. You can rename trait methods and override
them with methods with incompatible signatures and do other similar
stuff to make this use case a nightmare.

Therefore this:

and then where needed checking for the existence of
the trait to tell if the functionality is supported or not (think
along the lines of if a trait could implement an interface).

is totally impossible to do. A trait with a method does not guarantee
you that the method is available.

Anton

[IDEA for RFC] class_uses and optionally returning traits for parent classes

Mon, 20 Apr 2026 09:32:03 +0000

Le 19 avr. 2026 à 21:01, Robert Humphries contact@developer-rob.co.uk a écrit :

I think this is
the strongest argument for making such a change to class_uses -
currently it is inconsistent with the other SPL functions (and I
wouldn't say that modifying the function is going to cause millions of
developers to start using the function, it is more about making the
behaviour a little more consistent).

I think that class_uses() should never have been implemented, because it gives a false sense of symmetry with class_implements() and class_parents(). Implemented interfaces and parent classes can be used as types on the corresponding object (and types are inherited), while used traits cannot. Those are fundamentally different concepts.

If, for some reason, you want to “cheat” and use traits as if they were inherited types, you are free to do that, but I don’t think that PHP should provide a built-in function that goes beyond what traits are intended for.

(As a quick side note, what I am really looking for proposal 2 from
https://wiki.php.net/rfc/traits-with-interfaces (or a form of trait
that does this) and then using traits with interfaces for composition,
however from what I can see on activity such as GH-11435 technical
reasons mean this isn't likely to proceed).

See also https://wiki.php.net/rfc/interface-default-methods, which is, I think, what is really needed.

—Claude

[RFC][Discussion] Add MariaDB-specific features to mysqlnd and mysqli

Sun, 19 Apr 2026 21:07:15 +0000

Hi Robert,

When I designed and wrote mysqli (and parts of libmysql 4.1) nearly 25
years ago, the computing landscape was fundamentally different. Memory was
a severe constraint; allocating large buffers to send data all at once was
often impossible. This necessitated the use of mysql_stmt_send_long_data to
stream larger BLOBs in portions—which was a primary reason for requiring
the explicit types specification in mysqli_stmt::bind_param.

Furthermore, CPU power was significantly more limited. The overhead of
converting types between the client and server was expensive. By providing
explicit type hints (like "isss"), we gave the engine a shortcut, bypassing
the need for the driver to "guess" or perform trial-and-error casts, thus
saving precious cycles at both ends of the connection.

Twenty-five years later, the landscape has evolved. Physical memory is
rarely the bottleneck; we are now primarily limited by the
max_allowed_packet size. Modern hardware and the maturity of libraries mean
that the CPU cost of internal type-juggling is now negligible for the vast
majority of applications.

However, we must avoid the "sledgehammer" approach of deprecation. In
high-speed, high-concurency environments where packet size and execution
speed remain fundamental requirements, the ability to explicitly define
types is still important. It allows for the most efficient binary
serialization possible, which is critical for the "power-user" tier of the
PHP ecosystem.

/Georg

On Sun, Apr 19, 2026 at 3:45 PM Robert Humphries <
contact@developer-rob.co.uk> wrote:

Despite your convincing arguments for better network utilization by
providing the types, I still think we should not offer the possibility
of specifying the types. I don't know what other PHP developers on
this mailing list think about it, but for me the type feature goes
against the nature of PHP. Making the parameter optional is very good
choice and eases my concerns slightly, so if I am outnumbered in my
opinion, I won't be upset.
The number of mysqli users grows increasingly smaller. Out of this,
the number of people who will use execute_many and who will need to
optimize for TINYINT is unbelievably tiny. Any string easily
overshadows the numerical data. Thus, this feature won't see much
legitimate use.

I think the risk here is that currently the types parameter is
supported in existing code (via bind_param); and it is not
deprecated / no warnings exist on its usage in the manual. I think
having the parameter in new code be optional was a sensible change;
but until mysqli_stmt::bind_param is deprecated or the types
parameter is removed there; allowing users to specify the types in new
functions where there is a benefit to doing so (even if only a small
number of people will use the benefit) makes sense to do unless there
are technical or other reasons not to. If setting types for a prepared
statement shouldn't be done in PHP, then where that currently can be
done should be deprecated and in the future removed.

--
Georg Richter, Staff Software Engineer
Client Connectivity
MariaDB Corporation Ab

[IDEA for RFC] class_uses and optionally returning traits for parent classes

Sun, 19 Apr 2026 19:01:40 +0000

Sorry for the delay here, been quite busy with other work related tasks.

Frankly I don't like the existence of these 3 functions in SPL.
This is very much in Reflection territory, and it should only ever be in Reflection.
SPL is already a mess of badly designed "features" trying to cohabitate.
The Reflection extension is designed to give you access to do introspection with a well-defined API.

I don't necessarily disagree with this, especially about SPL in
general; however we are at a point where we have them currently (and
the functions are not deprecated/warned against use/etc). That said, I
certainly wouldn't be suggesting adding the function if it didn't
already exist.

But more over I don't even think you addition makes that much sense.
Traits are not part of the inheritance hierarchy, that's because the "composition" of traits is effectively just copy and paste.
Interfaces are fully inherited onto any child class, so there is no need to iterate through the parents to gather all interfaces.
Traits do not work this way, any "prior" use information is not transmitted due to the copy and paste nature of them.

Note with this, the same constraints apply to parent classes in terms
of the information stored in C - and ReflectionClass will return
only the parent as opposed to grandparents/etc; but class_parents
returns the parent class / grandparent class / etc. I think this is
the strongest argument for making such a change to class_uses -
currently it is inconsistent with the other SPL functions (and I
wouldn't say that modifying the function is going to cause millions of
developers to start using the function, it is more about making the
behaviour a little more consistent).

The current API doesn't even tell you if used traits also use other traits.
As per your example, ReflectionClass::getTraits also does not tell
you about any traits used by other traits, you need to query the
ReflectionClass for the trait returned by 'getTraits'. class_uses
will also accept a trait for $object_or_class, returning the traits
that trait uses. I would suggest that if a change was made to
class_uses to support optionally returning inherited traits then it
returning traits used on traits or the parent class would make sense.

I don't even know how it handles trait aliases, or if it even cares about them.
And that's not even going through overridden trait methods/props/constants at any stage of the inheritance chain.
class_uses seems to just return the names of the traits (mirroring
getTraitNames on ReflectionClass as far as I can tell).

So I'm very much not convinced about this, nor do I see really the utility of wanting this information?
But anyway here is a small snippet that will fetch all used traits: https://3v4l.org/kvQGR
In a private / tightly controlled codebase we are using a set of
traits to implement certain functionality at a higher level in the
inheritance chain; and then where needed checking for the existence of
the trait to tell if the functionality is supported or not (think
along the lines of if a trait could implement an interface). There are
various reasons why it isn't easily possible to use interfaces
directly on the relevant classes themselves in the particular codebase
(mainly related to refactoring work required as opposed to technical
reasons) - currently we have gone with a reduced version of the
example code (as we only need to know the names of traits implemented
by the classes as opposed to from traits using traits for our exact
use-case).

(As a quick side note, what I am really looking for proposal 2 from
https://wiki.php.net/rfc/traits-with-interfaces (or a form of trait
that does this) and then using traits with interfaces for composition,
however from what I can see on activity such as GH-11435 technical
reasons mean this isn't likely to proceed).

I guess the important questions is that regardless of the people's
thoughts on the functions themselves, what are the
benefits/disadvantages of making the change to the pre-existing
function (and if there are more benefits compared to disadvantages, do
those benefits justify introducing the change)? The example code
proves that the information can be gained from userland code; but the
code isn't a straight forward example - and I suspect it is a lot
slower (however you are not likely to do a large number of calls to
the userland or internals code). I still think personally is the
biggest benefit is it brings the behaviour of the three class_XXXX
functions in SPL fully inline with each other (that they all return
the parents/interfaces/traits that the class or any related
classes/traits use); and I am not seeing any disadvantages except that
the change not necessary (but I don't think any implementation would
be complex or hard to maintain - my thoughts here would it would
basically be the while in php_spl.c lines 125-128 (in
class_parents) plus if it was decided to include traits included by
traits then a similar check or recursive call to get traits used by
each trait in the array).

PHP Manual: Including phpc.tv PeerTube on the Tutorial What's Next page

Sun, 19 Apr 2026 16:17:08 +0000

Hi all,

I've proposed an update to the "What's Next" section of the Tutorial in
the PHP Documentation which includes, among other resources, a link to
https://phpc.tv - a community run PeerTube video site.

It's been raised that this should perhaps be discussed on internals
before inclusion.

PR: https://github.com/php/doc-en/pull/5491

I think it's particularly valuable in this section of the manual because
it fulfills multiple purposes:

Content includes video tutorials, for those who prefer them
Showcases a variety of current tools, frameworks and libraries
Advertises podcasts people can follow
Conference talks (in this regard it effectively replaces talks.php.net
on this page, which hasn't had any new talks uploaded in recent years,
and only includes the slides)

The PHP site and manual is already including links to wider community
content, such as Composer / Packagist, and various community run sites /
Discords on the "Help" page.

It's run by prominent community members (under the PHPC Collective[0]
who also run the phpc.social Mastodon ) and I know that Anna Filina
specifically is one of the people working directly on it[1].

Given who runs it, I consider it a safe resource that's likely to show
up-to-date content for a significant amount of time.

Does anyone feel https://phpc.tv should not be included in the official
documentation here? Other thoughts?

(Any further suggestions for the revised What's Next page are welcome too)

[0] https://opencollective.com/phpcommunity/projects/phpc-social
[1] https://afilina.com/why-phpc-tv

[RFC] [Discussion] array_get and array_has functions

Sun, 19 Apr 2026 15:06:19 +0000

Am 2026-04-18 08:06, schrieb Barel:

array_path_exists. I have preferred to keep get in the function
name
because I think that array_path is less clear about what the function
does. RFC and implementation have been updated.

No strong preference regarding the _get() suffix from my side.

I am still unconvinced about this. Your proposal seems to give the
null
a special value and I think that in general the full semantics are less

null being a value indicating absence is by no means “special” in my
suggestion. As previously mentioned, it's the semantics of isset().
It's also what array_find() and array_find_key() return. It has
special syntax in types with the questionmark in ?Type. It's what you
get when you read a non-existent value.

clear. And I don't really like the function throwing errors for paths,
I
think that this function is great for defensive access to values, where
you
can be sure that you don't need to be checking the path all the time.
The

Defensive access to me also implies throwing errors where appropriate,
namely trying to perform an operation that is not meaningful. Trying to
access an array offset on a string is not meaningful and trying to do
something is not likely what the user intended to do. Similarly users
passing in ArrayAccess objects might reasonably expect them to “just
work”. Returning a default value instead of a clear error will likely
lead to them thinking they found a bug in PHP.

existing implementations in Laravel and Lodash do not throw any error
if an
intermediate value is not an array (or object for Lodash) and instead
return the default, so I think it is best to keep this behaviour

I don't think that lodash is quite comparable here, because JavaScript
is quite different to PHP in that everything is an object. Thus
_.get({"foo": "bar"}, "foo.length.toString") is meaningful (namely it
returns Number.prototype.toString()).

As for the Laravel comparison, from what I see, they do support any
ArrayAccess, so the function is also not comparable.

I've also taken another look at the RFC and have the following
additional comments:

The “Invalid array path segments” example is outdated, stdClass in
the path should throw.
The types of the path-segments should be pre-validated for consistent
error reporting. Meaning:

array_path_get($array, ['foo', 'bar', new stdClass()])

should consistently throw, independent of whether $array is [],
["foo" => []], ["foo" => ["bar" => []] or something else.

I also wonder if $path should just be string[] instead of
(int|string)[]. In the context of array keys, "123" is equivalent to
123 anyways.

Best regards
Tim Düsterhus

[RFC][Discussion] Add MariaDB-specific features to mysqlnd and mysqli

Sun, 19 Apr 2026 13:44:48 +0000

Despite your convincing arguments for better network utilization by
providing the types, I still think we should not offer the possibility
of specifying the types. I don't know what other PHP developers on
this mailing list think about it, but for me the type feature goes
against the nature of PHP. Making the parameter optional is very good
choice and eases my concerns slightly, so if I am outnumbered in my
opinion, I won't be upset.
The number of mysqli users grows increasingly smaller. Out of this,
the number of people who will use execute_many and who will need to
optimize for TINYINT is unbelievably tiny. Any string easily
overshadows the numerical data. Thus, this feature won't see much
legitimate use.

I think the risk here is that currently the types parameter is
supported in existing code (via bind_param); and it is not
deprecated / no warnings exist on its usage in the manual. I think
having the parameter in new code be optional was a sensible change;
but until mysqli_stmt::bind_param is deprecated or the types
parameter is removed there; allowing users to specify the types in new
functions where there is a benefit to doing so (even if only a small
number of people will use the benefit) makes sense to do unless there
are technical or other reasons not to. If setting types for a prepared
statement shouldn't be done in PHP, then where that currently can be
done should be deprecated and in the future removed.

[RFC] [Discussion] `#[\Override]` for class constants

Sun, 19 Apr 2026 01:19:45 +0000

Hi internals,

I have updated the RFC to resolve the open issue about #[\Override] on
enum cases - when marked with #[\Override], the enum case must be
overriding an inherited class constant. The fact that this is so uncommon
makes it all the more important that when it is intentional, it can be made
clear.

This qualifies as a "major change" to the RFC and triggers a 14 day
cooldown period.

-Daniel

On Mon, Mar 30, 2026 at 4:36 PM Daniel Scherzer daniel.e.scherzer@gmail.com
wrote:

Hi internals,

I'd like to start the discussion for a new RFC about adding support for
#[\Override] for class constants.

RFC: https://wiki.php.net/rfc/override_constants

Implementation: https://github.com/php/php-src/pull/20478

I'd also like to draw specific attention to the open question, which I am
soliciting feedback on: how should #[\Override] work for enum cases? See
the RFC page for details.

Thanks,
-Daniel

[RFC] [Discussion] array_get and array_has functions

Sat, 18 Apr 2026 06:06:54 +0000

Hi

Am 2026-04-14 19:06, schrieb Barel:

I see the point that Tim made about the function names, I have
updated
them to array_get_path() and array_has_path()

Similarly to Rob's tongue in cheek comment, I think I would also prefer
having a common prefix for the functions, since this improves
discoverability. While there are some inconsistencies in the array API
due to its age, I think there is a reasonably similar precedent with the
array_key_*() functions. In fact looking at those, I wonder if the
following pair of names would make sense for your proposed feature:

array_path()

array_path_exists()

From what I see, the functions in the array API don't mention “get” as
the default operation, e.g. it's array_first(), not
array_get_first(). And for “existence checks” there's the obvious
precedent with array_key_exists() which is also used in the example
implementation in your RFC.

Tim, thanks again for your comments. I did not like using array_path._...
because the function name reads less naturally, but I agree that it
improves discoverability and is more in line with existing functions like
array_key_exists. Also agree that using exists instead of has is
better. So I updated the function names to array_path_get and
array_path_exists. I have preferred to keep get in the function name
because I think that array_path is less clear about what the function
does. RFC and implementation have been updated.

Regarding the issue of returning the default if an intermediate
segment
is not an array, the philosophy of the function is: if the path exists,
return the value, otherwise return the default. This cover uses cases
like
this: in yaml configuration many times you set a config option to ~
(null)
and this many times indicates "use the default config". So you may have
something like:

database:
config: ~

Indicating that you want to use the default database config. If you
convert
this yaml file to an array an use the array_get_path function to get a
value, for example array_get_path($config, ['database', 'config',
'port'],
7766), you want to get 7766, not an exception or error. Tim points out
that
intermediate segments might be objects which implement ArrayAccess, but
allowing this would complicate the code of the function a lot without
much
practical gain.

Perhaps the right solution is using “isset”-like semantics instead:
null is treated as an absent entry (it can be debated if an explicit
null at the end of the path should be treated as null rather than
the default), array allows the traversal to continue and everything else
results in a clear error. This would then allow to extend support to
anything ArrayAccess in the future without a compatibility break.
Generally “throwing an error” is always a safe option.

But saying that array_get_path(['foo' => '???'], ['foo', 'bar'], 'default'); should result in 'default' doesn't make sense to me and -
staying with the config example - might mask configuration errors:

As an example, a user might accidentally configure a "DSN":
 database:
     connection: "mysql://root@db.example.com"
when in reality the library expects separate components:
 database:
     connection:
         driver: mysql
         host: db.example.com
         user: root
Now extracting the host with array_get_path($config, ['database', 'connection', 'host'], 'localhost') would erroneously fall back to
default values instead of reporting a clear error.

I am still unconvinced about this. Your proposal seems to give the null
a special value and I think that in general the full semantics are less
clear. And I don't really like the function throwing errors for paths, I
think that this function is great for defensive access to values, where you
can be sure that you don't need to be checking the path all the time. The
existing implementations in Laravel and Lodash do not throw any error if an
intermediate value is not an array (or object for Lodash) and instead
return the default, so I think it is best to keep this behaviour

Cheers

Carlos

[VOTE] RFC: Debugable Enums

Sat, 18 Apr 2026 00:35:32 +0000

Hi internals,

I forgot to do the needful yesterday, but the RFC passed! Final result was
16 votes in favor, 2 votes against, and 5 abstentions.

I'll land the implementation soon.

-Daniel

On Thu, Apr 2, 2026 at 10:01 AM Daniel Scherzer daniel.e.scherzer@gmail.com
wrote:

Hi internals,

Voting is now open for this RFC.

RFC: https://wiki.php.net/rfc/debugable-enums

Discussion thread: https://news-web.php.net/php.internals/130303

Voting will end 2026-04-16 at end-of-day UTC.

-Daniel

[RFC proposal] Syntactic sugar for array push()

Fri, 17 Apr 2026 09:11:57 +0000

Can someone create 2 votes?:

[-] for array_pop

[+] for array_push

I don't have an account and rights; and let the discussion have a practical
outcome (whether with a positive or negative result)?

Hi Dušan,

Anyone is free to propose a change or feature, but before it goes to a vote, it has to be presented in a standard way, called an RFC. Writing that proposal is only a small amount of work, and we can help with parts you done understand, but it's unlikely that somebody will do it all for you.

If you would be interested in following up this proposal, you can see the instructions for creating an RFC here: https://wiki.php.net/rfc/howto

Best regards,

Rowan Tommins
[IMSoP]