Open asgrim opened 4 months ago
PHP in Debian and derivatives come with a php(en|dis)mod
script, that I think solves this problem fairly well. It accepts a SAPI name (all SAPIs by default), and creates a in formats such as 20-mbstring.ini
that only has extension=mbstring.so
. I like that it does not modify the main php.ini
file, but instead adds/removes these "loader" files in all/selected SAPI-specific conf.d
folders.
I suppose we can use php_ini_loaded_file()
/PHP_INI_SCAN_DIR
/php_ini_scanned_files()
to try and guess if we are in a Debian/RHEL-like environment, and if we detect a conf.d
in one of the scanned file paths, to add a "loader" ini file for the extension.
On Windows, I don't think PHP_INI_SCAN_DIR
is actively used, so in all other situations, we can modify the ini file.
When implementing this, please allow for a CLI option to disable it.
Currently, we use PECL to install extensions like xdebug. For reasons, we want xdebug to be installed, but not enabled. We always have to do post processing to remove the auto enabled extension from php.ini or conf.d/99-xdebug.ini.
So for PIE, it would be super nice to have --no-enable
or something.
Typically, the approach for adding
extension=blah.so
orzend_extension=blah.so
to the PHP INI would be:Scan for additional .ini files in:
using the priority defined incomposer.json
(e.g.20-myext.ini
)Scan for additional .ini files in:
is empty, add the line to the file indicated byLoaded Configuration File:
entryHowever, when using setups like the
deb.sury.org
PHP installer, this approach would ONLY enable the ext for a single SAPI (the CLI SAPI). This would be confusing as the extension would not be enabled for the Apache SAPI, so consumers may be confused by the fact it does not have the extension loaded!Investigate the various common approaches to how
php.ini
are used, and we may need to add special handling for each "custom" approach, and then fall back to the expected typical approach above.