Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120907
To: internals@lists.php.net
References: <CAFPFaMLBZixUFa=7=9Gxj60D=4QyfSpF9se-U+6CRoShzCrFrA@mail.gmail.com>
 <64DA7ACC.1050909@adviesenzo.nl>
 <CAFPFaMJ-TEA9xyvT5gRsGh-4jop-iRXBL+cFvPZSwpNRtXFUWw@mail.gmail.com>
Message-ID: <64DABDF7.5010400@adviesenzo.nl>
Date: Tue, 15 Aug 2023 01:51:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAFPFaMJ-TEA9xyvT5gRsGh-4jop-iRXBL+cFvPZSwpNRtXFUWw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090701090207050909090105"
Subject: Re: [PHP-DEV] Removing support for the disable_classes INI setting
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------090701090207050909090105
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 14-8-2023 22:11, G. P. B. wrote:
> On Mon, 14 Aug 2023 at 20:04, Juliette Reinders Folmer <
> php-internals_nospam@adviesenzo.nl> wrote:
>
>> Would deprecating it in PHP 8.3 and removing it in PHP 9.0 be an option ?
> One option is to "keep" the INI setting, but have it basically do nothing.
> Is this what you had in mind?
That sounds iffy as well in a way as people (hosts) may then "think" it 
works, while it doesn't.
Disabling the actually functionality (as broken) and then throwing a 
warning could possibly be a middle-of-the-road solution ?

Note - warning, not deprecation if the functionality is turned off in 
PHP 8.3.

With any luck, the hosts' error logs would fill up quickly enough for 
them to take notice ;-)
>
>> As for the lack of bug reports - the typical type of end users using
>> those hosts will not know to report these type of issues to PHP (or even
>> be able to properly identify the issue). Instead they will complain
>> extensively to whatever open source project (read: WordPress) they are
>> running on the shared hosting without providing enough information for
>> the open source maintainers to even begin to identify the actual
>> issue... ;-)
> On a minimal build of PHP, with only the mandatory extensions enabled,
> there are 148 classes/interfaces/traits defined. [1]
>
> Other than the SPL ones (and even then), disabling any of these classes
> will cause issues within the engine.
> Moreover, the SPL ones are not a security concern.
>
> Therefore, any other class that can be disabled must come from an extension
> that can be disabled altogether. And "disabling" a class from an extension
> without disabling said extension will render it useless anyway.
>
> If a hosting provided is concerned about an extension, then it should not
> enable it in the first place. Not break it ad hoc.
100% agreed. Unfortunately (in my experience), the hosts using this ini 
setting are generally not what anyone would consider high quality hosts 
who know what they are doing.... more the penny-and-dime teenager with a 
server in the attic type... (which is hopefully a dying breed, but I've 
seen too many of them come and go over the years - oh and apologies to 
the potential 
teenager-host-exception-to-the-rule-who-does-know-what-they-are-doing 
who may be reading this... ).

And the type of end-user I was talking about would describe it as "You 
broke my website"... (not realizing that it's not the open source 
package, but the hosting which broke it)
> Considering the above, I cannot see how this functionality was ever useful.
I have absolutely no doubts at all about your analysis. My only remarks 
were about how to communicate this effectively to the type of 
ill-informed hosts/end-users who will be affected by the removal.

Smile,
Juliette

--------------090701090207050909090105--