Re: Removing support for the disable_classes INI setting

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