Story #93818
open
Provide official way to split up configuration to multiple files
0%
Description
Currently, there is only AdditionalConfiguration.php to provide configuration for bootstrap.
This has these issues:- It is unnecessarily hard for configuration-changing environments (like ddev, container-deployment) to override or append to existing configuration
- Configuration files should semantically and from a security standpoint not be in public/
There are solutions but none of those really uses an established and well-known way to provide configuration.
I suggest to execute PHP files from ./etc/conf.d/*.php after AdditionalConfiguration.php.
This would lend to the well-known "run-parts" https://manpages.debian.org/stretch/debianutils/run-parts.8.en.html way of providing configuration. Run order is determined by lexical sorting. Usually a requirement like --regex=^[0-9] is added to allow easier deactivating for testing or example files. In UNIX world, files have to be executable, too but since permissions might be hard to handle for some TYPO3 users I would forfeit that.
This could be an example of files in ./etc/conf.d:- ./etc/conf.d/10-errorhandling.php
- ./etc/conf.d/20-proxy.php
- ./etc/conf.d/50-db.php
- ./etc/conf.d/500-ddev.php # added by a something for that specific environment
Those PHP files could use a guard clause like `applicationContext === ... || return;` or other logic to allow reacting to the environment/context.
In order to allow better grouping of contexts, integrators could use further directories but they would be on their own there. It would be nice if they could use a PHP `run-parts` implementation (I did not find a composer package yet).
For example- ./etc/RootApplicationContext/Production.conf.d/10-errorhandling.php
This proposal does not deal with an (also) much needed official way to parse environment variables into TYPO3_CONF_VARS but of course current logic of integrators in AdditionalConfiguration.php could be used here, too.
Updated by 
Updated by 
Updated by