Re: Removing support for the disable_classes INI setting

From: Date: Mon, 14 Aug 2023 20:11:54 +0000
Subject: Re: Removing support for the disable_classes INI setting
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-120902@lists.php.net to get a copy of this message
On Mon, 14 Aug 2023 at 20:04, Juliette Reinders Folmer < php-internals_nospam@adviesenzo.nl> wrote: > Hi George, > > For what its worth: in my experience, the disable_classes and > disable_functions ini directives are mostly used by hosting > companies > providing shared/virtual host environments and, most often for those > environments, not editable by their users via a control panel or nor do > these users have (edit) access to the php.ini file. > To be clear, I have no intention of deprecating or removing disable_functions. This INI setting works very well and does not cause any issue within the engine. [...] > > 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? > 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. Considering the above, I cannot see how this functionality was ever useful. This is in stark contrast to disable_functions, which can be used to selectively remove functionality of an extension without breaking it overall. George P. Banyard [1] https://gist.github.com/Girgias/63d55ba1e50b580412b004046daed02b

« previous php.internals (#120902) next »