Reconsider passed-by ini file on subprocess command execution
currently, the subprocess is executed with the currently loaded ini,
$command .= sprintf('%s -c %s %s %s', $phpBinaryPathAndFilename, escapeshellarg(php_ini_loaded_file()), ...
This results into, for example,
FLOW_ROOTPATH='/var/www/vhosts/acme.com/' FLOW_CONTEXT='Development' XDEBUG_CONFIG='idekey=FLOW_SUBREQUEST remote_port=9001' "/usr/bin/php" -c '/etc/php5/apache2/php.ini' '/var/www/vhosts/acme.com/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Core/../../../../Scripts/flow.php' 'typo3.flow:core:compile'
apache2/php.ini is included and used as ini for the subprocess.
In default cases, especially in apache's ini config a memory_limit is set; which therefore also engages CLI with a memory limit; which is surely not intended.
I think we should make this ini file configurable. Any ideas where and with what naming?
Updated by Adrian Föder over 8 years ago
How could the configuration for this look like?
IMO we have three states to cover:
- don't use any INI file explicitly
- use a defined path to an INI file
- use the
We could introduce a core setting similar to
core: # true: use the one from the current request, usually apache's subprocessIniFile: true # anything !== true: consider it a path subprocessIniFile: '/my/deriving/php.ini'
If not set at all or FALSE, don't use this setting...
I'm a bit unlucky of this of course because of the type flagging.
// edit: most logical, if at all, would be:
FALSE: don't use the setting
string: use that path
not set: behave like before