Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120908
MIME-Version: 1.0
References: <CAFPFaMLBZixUFa=7=9Gxj60D=4QyfSpF9se-U+6CRoShzCrFrA@mail.gmail.com>
 <64DA7ACC.1050909@adviesenzo.nl>
In-Reply-To: <64DA7ACC.1050909@adviesenzo.nl>
Date: Tue, 15 Aug 2023 04:43:14 +0300
Message-ID: <CAJW__o0LaFdeZTbrXf_EKeNChBxkUiMDos6D_ekR3Wovfq1htg@mail.gmail.com>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Removing support for the disable_classes INI setting
From: kalle@php.net (Kalle Sommer Nielsen)

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.

-- 
regards,

Kalle Sommer Nielsen
kalle@php.net