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 Christian Kuhn about 3 years ago
I'm totally with you that something should be done to allow different configurations for TYPO3_CONF_VARS in an easier way.
Some words on history: Back in the old days, there was localconf.php to set up TYPO3_CONF_VARS. The issue with that file was that it allows arbitrary PHP code and especially the install tool interface had a hard time to update these values. This was later changed to LocalConfiguration, which is an array - there is no code magic in there, which allows the install tool to properly set and update these values.
The code magic had then been extracted to "AdditionalConfiguration", as the 'ugly child': It allows developers to do whatever magic is needed. But it has the drawback that it destroys the install tool interface for parameters set in there: The install tool can only partially detect if some parameter is set in there, and writing values from within the interface to LocalConfiguation is ignored (-> interface settings have no effect) since they may or may not be overwritten by AdditionalConfiguration, which the install tool may not be able to detect.
Thus, I'd prefer to not extend the AdditionalConfiguration magic more, but look for suitable alternatives instead, that could finally obsolete this file altogether.
When looking at other frameworks, one solution in the room for quite a while, would be to finally implement proper 'environment / .env' support for LocalConfiguration.php: Extend the install tool interface to say "This value comes from THAT .env variable", and reflect this in LocalConfiguration. The bootstrap then would substitute these settings to the final values.
This way, typical settings like mailer or db credentials could come from .env which can be specific for given system (dev, staging, live, ...), the install tool would know about them and reflect handling in the interface. And AdditionalConfiguration could fall.
What do you think?
Updated by Georg Ringer about 3 years ago
I like the flexibility of the AdditionalConfiguration files but the magic needs to be in the hand of the integrator, checking the context and how to handle sub contexts..
I am all in for having .env support by the core which would solve all those stuff.
Updated by Jonas Eberle about 3 years ago
- environment variables for ddev and container-deployments
- symlinked .env -> .env.xxx for deployed systems
- helhum/dotenv-connector
- AdditionalConfiguration.php for parsing getenv() into TYPO3_CONF_VARS: https://gist.github.com/jonaseberle/1ed3b12e645667f2e1228f091fcaaa20
- environment variables / .env example:
TYPO3_CONF_VARS__SYS__caching__cacheConfigurations__hash__backend="TYPO3\CMS\Core\Cache\Backend\RedisBackend"
TYPO3_CONF_VARS__SYS__caching__cacheConfigurations__hash__options__compression=bool(false)
and it is "OK". It duplicates configuration if there are several, similar, deployment targets. It is clunky to work with arrays but possible. Since env is always string yet TYPO3 configuration is (rightfully) not, I had to add some "type converters". Also I realize it is not easy for other developers to grasp the meaning of those long keys.
Going with the proposed structure, .env/environment variables could be used to determine which directories are included (and if you agree, that could very well be by convention, not just "as the integrator wants it"):
For example:- we currently have contexts/subcontexts
TYPO3_CONTEXT=Production/Mailgun/Redis/Debian10_Gfx/Whatever - or
TYPO3_CONF_1=Production
TYPO3_CONF_2=Mailgun
...
- .env is a possibility to add/override environment variables, never the only way to configure. .env helps tremendously for giving configuration for a specific directory while containers lend to just using env variables directly. But I think we are on the same page there anyways?
- I would like to have more than just one file for 3rd-party programs/environments to add configuration. Putting additional configuration into a specific directory should "just work".
Regarding .env implementation: Yes, please. Of course.
Updated by Jonas Eberle over 2 years ago
I've just come across the demo.typo3.org way: https://git.typo3.org/services/demo.typo3.org/site/-/blob/main/web/typo3conf/AdditionalConfiguration.php
Simple, PHP only, well defined order of inclusion, configuration file names derived exactly from the contexts + subcontexts.
This puts the Context upfront. This reduces the amount of code that needs to be processed for every request.