Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111206
MIME-Version: 1.0
References: <CAB2bceYYB6GpuPU=zdMZi-Xo7=jO9DdhGFEBnWwyqsQ5wagwrQ@mail.gmail.com>
 <CAEUnE0cONReq7ciwwFOw3_dkHwDoVW4xJwFLHoYro0amxTz-Mw@mail.gmail.com> <CABdc3WpQqSSSnBkUhUG6jPZ_r7YNDEumFDm9Z98zZSZf=TXRWQ@mail.gmail.com>
In-Reply-To: <CABdc3WpQqSSSnBkUhUG6jPZ_r7YNDEumFDm9Z98zZSZf=TXRWQ@mail.gmail.com>
Date: Mon, 27 Jul 2020 22:26:48 -0500
Message-ID: <CAEUnE0d=ON9Lp_mu-JvNSc6+jy5zNG3ZS+6_5G1jpyk2e-kWww@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000006b70e05ab780364"
Subject: Re: [PHP-DEV] Proposal: php.ini environment variable fallback value
From: tendoaki@gmail.com (Michael Morris)

--00000000000006b70e05ab780364
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 27, 2020 at 12:18 AM Micha=C5=82 Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi Michael,
>
> niedz., 26 lip 2020, 06:22 u=C5=BCytkownik Michael Morris <tendoaki@gmail=
.com>
> napisa=C5=82:
>
>> PHP's ini values are already a bit of a mess.  You have a global php.ini
>> file, and then most PHP ini directives can be set per directory using th=
e
>> .htaccess file.  About a third can be set at runtime. This makes trackin=
g
>> down where a setting came from a bit of a headache unless care is taken.
>> This proposal promises to make the situation even more complicated.
>>
>> Also, what would this solve that using .htaccess files to override the
>> default values not solve aside from the rare settings that cannot be set
>> per directory?
>>
>
> Bear in mind that .htaccess has a very narrow use and it's kind oh thing
> Apache2 related and not PHP specific!
>

Most major webserver applications have an equivalent to .htaccess. Indeed,
IIS can bind PHP flags and values to environment values already if I recall
correctly, and has been able to do so for a very long time (though I
haven't played with IIS in over a decade so my memory could be wrong on
this).

You mention Docker - usually I've seen it used alongside Ansible, Chef or
Puppet. Each of these provisioning programs can modify the php.ini file
used on the container at deploy time without necessitating a change to PHP
itself.  What advantage does the community gain from moving these decisions
from the provision files to the php.ini file?


>

--00000000000006b70e05ab780364--