Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120911
To: internals@lists.php.net
References: <CAFPFaMLBZixUFa=7=9Gxj60D=4QyfSpF9se-U+6CRoShzCrFrA@mail.gmail.com>
 <64DA7ACC.1050909@adviesenzo.nl>
 <CAJW__o0LaFdeZTbrXf_EKeNChBxkUiMDos6D_ekR3Wovfq1htg@mail.gmail.com>
Message-ID: <64DBA5B2.9060700@adviesenzo.nl>
Date: Tue, 15 Aug 2023 18:20:02 +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: <CAJW__o0LaFdeZTbrXf_EKeNChBxkUiMDos6D_ekR3Wovfq1htg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090500080905060004020107"
Subject: Re: [PHP-DEV] Removing support for the disable_classes INI setting
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------090500080905060004020107
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 15-8-2023 3:43, Kalle Sommer Nielsen wrote:
> Hi
>
> Den man. 14. aug. 2023 kl. 22.05 skrev Juliette Reinders Folmer
> <php-internals_nospam@adviesenzo.nl>:
>> 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.
>>
>> Declaring an ini directive in the php.ini file which has been removed
>> will instantly cause a fatal error on starting PHP, so I wonder what the
>> impact will be when a user switches PHP version (which they often can
>> choose to do via a control panel).
> This depends on whether we choose to explicitly mark the ini directive
> as one such. As the original implementor of that logic, it was meant
> as an upgrade tool for PHP 5.3.0 when we also reorganized the php.ini
> files, rather than have developers just copy over their old,
> non-working files over to cause unexpected features to still be
> available.
>
> So there is always the option to not enlist it there, though it would
> be ideal to do so to prevent developers from getting a false sense of
> "security", but that is just my personal take.
>
Ah, that explains it! Thanks for adding that context Kalle!

--------------090500080905060004020107--