Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.
Best regards,
Gina P. Banyard
Hi
As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of
August 2026 at 13:00:00 UTC.Please remember that the wiki is only capable to handle a single vote
at a time,
so each vote MUST be submitted individually.
It seems the RFC title didn’t make it into the email subject. I'm
sending this reply to fix the Subject for proper visibility. It's still
before 13 UTC, so there's still two full week for the vote.
Best regards
Tim Düsterhus
Hi
As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of
August 2026 at 13:00:00 UTC.Please remember that the wiki is only capable to handle a single vote
at a time,
so each vote MUST be submitted individually.It seems the RFC title didn’t make it into the email subject. I'm
sending this reply to fix the Subject for proper visibility. It's still
before 13 UTC, so there's still two full week for the vote.Best regards
Tim Düsterhus
I have missed the "Deprecate define() with $case_insensitive being
specified" before it went to vote, but I wonder why do we need to
deprecate it. If the feature is gone and the deprecation happened
already in the past, then what's left is just to clean it up by
removing the redundant parameter. By removing the parameter we cannot
break any userland code, so modifying the warning message won't help
with anything.
Hi
removing the redundant parameter. By removing the parameter we cannot
break any userland code, so modifying the warning message won't help
with anything.
For native functions passing parameters in excess of the function’s
arity will throw an ArgumentCountError:
php > define('X', 'X', true, 'extra');
PHP Warning: Uncaught ArgumentCountError: `define()` expects at most
3 arguments, 4 given in php shell code:1
Making it explicit (and deciding) that the parameter will go in PHP 9 is
a good thing.
Best regards
Tim Düsterhus
Hi
As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of
August 2026 at 13:00:00 UTC.Please remember that the wiki is only capable to handle a single vote
at a time,
so each vote MUST be submitted individually.It seems the RFC title didn’t make it into the email subject. I'm
sending this reply to fix the Subject for proper visibility. It's still
before 13 UTC, so there's still two full week for the vote.
and even if it was not, we should allow it.
If we would not, it would be a complete non sense and we need to sit down
to sort this out :)
--
Pierre
@pierrejoye
Hi,
As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
At the time I'm the only one who voted "no" on
https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filter
As things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.
I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
"find an alternative, such as decoding it using code written in PHP".
My 2c.
Cheers
Matteo Beccati
Hi,
Hi,
As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
At the time I'm the only one who voted "no" on
https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filterAs things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
"find an alternative, such as decoding it using code written in PHP".
On a side note in this "official" thread, I added gd and gd2 image
related functions to the list. I suppose they don't need a vote, as I
don't see them either in the "removed" list. They will effectively not
be available in php 9. And GD itself will do a deprecation warning in
8.7.
Cheers,
Pierre
@pierrejoye
Hi,
As announced last week I've opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
At the time I'm the only one who voted "no" on
https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filterAs things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
"find an alternative, such as decoding it using code written in PHP".
I think this should have not been proposed for deprecation yet. There are
significant users of it and I just didn't have time to properly look into
the issues. So there might be options to get it fixed properly. So I think
it should wait till it's properly investigated.
Kind regards,
Jakub
Hello,
I think this should have not been proposed for deprecation yet. There are significant users of it and I just didn't have time to properly look into the issues. So there might be options to get it fixed properly. So I think it should wait till it's properly investigated.
I took a bit of time to actually check what is used, realistically,
beyond keywords presence stats.
I think there is some data/stats misinterpretation here. Being present
in a code base does not automatically mean it is used.
For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227
Guzzle and Symfony default to curl too. As curl is optional, I would
be surprised if a large majority of users do not have curl. Even more
surprised as, it is also a composer required dep.
Some SAPIs or php servers like FrankenPHP take over this as well
before PHP gets a hand on it. Please correct me here if my memory
fails here :)
From a http "end user" perspective, I would rather define that as
effectively not used.
The only part the deprecation does not address directly is the
fopen&co internal usages.
I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Cheers,
Pierre
@pierrejoye
Hi Pierre,
Il 28/07/2026 05:52, Pierre Joye ha scritto:
For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227
FYI, Symfony has implemented a pure-PHP alternative in 8.2:
https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2
That's why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:
stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);
in the code, if for whatever reason the Curl client is not in use.
I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.
Cheers
Matteo Beccati
Hey Matteo,
Hi Pierre,
Il 28/07/2026 05:52, Pierre Joye ha scritto:
For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227FYI, Symfony has implemented a pure-PHP alternative in 8.2:
https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2
That's why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);
in the code, if for whatever reason the Curl client is not in use.
I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.
Thanks :)
I miss the 8.2 switch. That being said, deprecation is for php 9
removal as a target ideally. Keeping stream_filter_append that brings
little to support users to migrate to a final solution earlier. Half
baked deprecation can lead to missing places where implementation
should be updated (not in project mentioned here tho' but many
internal code out there).
Cheers,
Pierre
@pierrejoye
Hi
Hey Matteo,
Hi Pierre,
Il 28/07/2026 05:52, Pierre Joye ha scritto:
For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment inFYI, Symfony has implemented a pure-PHP alternative in 8.2:
https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2
That's why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);
in the code, if for whatever reason the Curl client is not in use.
I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.Thanks :)
I miss the 8.2 switch. That being said, deprecation is for php 9
removal as a target ideally. Keeping stream_filter_append that brings
little to support users to migrate to a final solution earlier. Half
baked deprecation can lead to missing places where implementation
should be updated
This is exactly a half baked deprecation because we need to keep it for
internal use anyway (it’s used http stream wrapper for chunked encoding) so
this does not give us any code removal and we still need to maintain it. I
don’t understand why we need to rush it as there is no real reason for that.
Also we cannot just decide not to deprecate it in RC. We would need extra
approval from RM and then new RFC. We had exactly this sort of situation
last year with __sleep and it was huge pain to change. It also took lots of
our time that we could use for much more important stuff.
Kind regards,
Jakub
Hey Jakub,
This is exactly a half baked deprecation because we need to keep it for internal use anyway (it uses http stream wrapper for chunked encoding) so this does not give us any code removal and we still need to maintain it. I don’t understand why we need to rush it as there is no real reason for that.
Yes and no. Having internal uses only down the road is significantly
easier to deal with than having to support this from a userland
perspective. There is some time to think about it and make it cleaner
or safer to be used for the purpose of fopen/file_get_contents like
usages. But the select issues may remain, not sure yet. I don't think
this is something that can't be solved.
Also we cannot just decide not to deprecate it in RC. We would need extra approval from RM and then new RFC. We had exactly this sort of situation last year with __sleep and it was huge pain to change. It also took lots of our time that we could use for much more important stuff.
I hear you.
Important has very different lists depending who we talk to. And
everyone has time when it is possible, being paid to do it or in their
free time. Cumulated time to deal with something we know is broken and
we could fix in a decade or more surely used an order of magnitude
time for too many people than reveriting a deprecation or adapting it.
Even if it happens some RMs will need to deal with it, but you and
others are not alone, dropping a mail here does not hurt and I am sure
some, or I when I know the area, can jump in too. Communication is
sometimes hard but amazingly helpful :).
Cheers,
Pierre
@pierrejoye
Hi,
Hey Jakub,
This is exactly a half baked deprecation because we need to keep it for
internal use anyway (it uses http stream wrapper for chunked encoding) so
this does not give us any code removal and we still need to maintain it. I
don’t understand why we need to rush it as there is no real reason for that.Yes and no. Having internal uses only down the road is significantly
easier to deal with than having to support this from a userland
perspective. There is some time to think about it and make it cleaner
or safer to be used for the purpose of fopen/file_get_contents like
usages. But the select issues may remain, not sure yet. I don't think
this is something that can't be solved.
I actually resolved that select issue (if it's what I think it is -
limitation using select on filtered streams which I got rid of) in the
current master so it will be part of 8.6. See
https://github.com/php/php-src/pull/20540 .
Also we cannot just decide not to deprecate it in RC. We would need
extra approval from RM and then new RFC. We had exactly this sort of
situation last year with __sleep and it was huge pain to change. It also
took lots of our time that we could use for much more important stuff.I hear you.
Important has very different lists depending who we talk to. And
everyone has time when it is possible, being paid to do it or in their
free time. Cumulated time to deal with something we know is broken and
we could fix in a decade or more surely used an order of magnitude
time for too many people than reveriting a deprecation or adapting it.
Even if it happens some RMs will need to deal with it, but you and
others are not alone, dropping a mail here does not hurt and I am sure
some, or I when I know the area, can jump in too. Communication is
sometimes hard but amazingly helpful :).
The problem is that there wasn't enough time to properly investigate if the
things can be improved on the C side. There was just some bug and then
immediate proposal to deprecate it without first not even realising that
it's used by chunked encdoing which I needed to point out. Then the idea
was to deprecate it for user space only which I actually wasn't against as
I assumed there was a proper research into the the usage but that wasn't
the case because Nicolas then pointed out that it is used in Symfony but
the deprecation proposal didn't get removed.
What I think is that deprecation should be proposed only if there a deep
knowledge of the problem and the context which I'm not sure is the case
here (and in some other proposals as well).
Kind regards,
Jakub
Hi,
Seeing this discussion during the voting phase makes me think the discussion phase wasn't properly completed yet, and I did a poor job in merging all opinions into a RFC proposal. I would rather not fuel the discussion any further, but I would prefer to let the voting play out.
Jakub Zelenka wrote:
The problem is that there wasn't enough time
I don't know your situation, but it seems you have quite a lot of work on your plate. Is there something I or anyone can do to reduce your load?
This is exactly a half baked deprecation because ... this does not give us any code removal and we still need to maintain it.
This is true, but my goal was to prevent abuse of the dechunk filter in filter chain attacks, not to reduce maintainance load. See also my PR to make filter chain attacks more difficult: https://github.com/php/php-src/pull/22110
to properly investigate if the things can be improved on the C side.
I tried some solutions, the most promising here: https://github.com/php/php-src/pull/22548
There was just some bug and then immediate proposal to deprecate it without first not even realising that it's used by chunked encdoing which I needed to point out.
For reference, this was in https://github.com/php/php-src/pull/22036, and there is some more information in https://github.com/php/php-src/issues/21983.
Regards,
Sjoerd Langkemper
Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
Since Juliette kindly added some raw usage data, but proposers have refused to spend any time looking at it, I would like to point out that one of the uses found for "is" as a keyword is in Hamcrest, a cross-language test assertion framework. The PHP version has 500 million installs tracked by Packagist.
The is() function is part of the design inherited from the original Java library, and is used in many of the examples in the README so is likely to be widely used in the wild: https://github.com/hamcrest/hamcrest-php#usage
I think we should think very carefully whether we can avoid disrupting that much code.
Rowan Tommins
[IMSoP]
Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.Best regards,
Gina P. Banyard
Nora isn't on the list, but she points out:
The text for the metaphone deprecation isn't fully right. It lists
"linguistics" as a replacement package, but that one actually uses
php-src's metaphone internally too. So it is affected by the
deprecation, not a replacement.
As demonstrated by:
<?php
require 'vendor/autoload.php';
\Linguistics\Phonetics::metaphone('foo');
> Nora isn't on the list, but she points out:
>
> The text for the metaphone deprecation isn't fully right. It lists
> "linguistics" as a replacement package, but that one actually uses
> php-src's metaphone internally too. So it is affected by the
> deprecation, not a replacement.
>
> As demonstrated by:
>
> <?php
> require 'vendor/autoload.php';
> \Linguistics\Phonetics::metaphone('foo');
Thanks for noticing.
Worth noticing that only the Phonetics::metaphone function use php's
metaphone(). Also, that function is barely a bridge for applying
existent functions of PHP. All other advanced algorithms ain't affected
by the metaphone deprecation.
My point in deprecating it is to stop using ancient metaphone algo as a whole.
And Linguistics offers loads of implementation. So this is still a replacement.
However, I do see the reason to make this clear in the RFC text.
I also forward this to Nora.
- Weilin
Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.
As a reminder to everyone, one week remains for voting on the mass 8.6 deprecation RFC.
Best regards,
Gina P. Banyard