php
php copied to clipboard
docker-library
Add environment variable for PHP_FPM_DIR
Changed the title because "expose" could mean make accessible outside the container
@tclavier to get the change in, you would need to run ./apply-template for the changes to be applied to the image themselves.
@tclavier to get the change in, you would need to run
./apply-templatefor the changes to be applied to the image themselves.
@LaurentGoderre it's done
Issue https://github.com/nextcloud/docker/pull/1766 is waiting for this one :-)
Sorry, I think I'm missing some context here (just got off some long PTO) -- what problem is this solving?
Sorry, I think I'm missing some context here (just got off some long PTO) -- what problem is this solving?
There is some fpm configuration that goes directly into the PHP_FPM_DIR folder, and :
- if the path of this folder changes, it would be good to drop the configuration in the right folder.
- It's more explicit to write $PHP_FPM_DIR/myfile.ini than /usr/local/etc/php-fpm.d/myfile.ini.
I don't think it's changed in the roughly nine years since FPM was added :sweat_smile:
My concern with adding it as an explicit ENV like this is that it implies that it might be something we could change at runtime, but the change won't actually apply, and it doesn't really save many characters for users either.
I'm not trying to save characters, but to make it explicit and readable. And I find it really simple to find out where the fpm conf is by exploring the environment variables. There's a PHP_INI_DIR variable and the first instinct is to put all the php configuration in PHP_INI_DIR ... but for fpm it's the wrong folder.
If I have to choose between these different options :
$PHP_FPM_DIR/myfile.ini/usr/local/etc/php-fpm.d/myfile.ini.$PHP_INI_DIR/../php-fpm.d/myfile.ini
I have a strong preference for option 1, I find it easier to read and more explicit.
I guess I'm trying to say that if I wrote this Dockerfile fresh today, I probably wouldn't even include ENV PHP_INI_DIR in it, and breaking users is the only reason I'm not considering removing it retroactively (but might consider doing so in a PHP-version conditional for future releases). :see_no_evil: