LocalConfiguration.php is excluded in .gitignore about typo3.cms.basedistribution

[Phosphenius]

I don't see how it's fine like this. Putting all secret and environment specific configuration into .env is very cumbersome and IMO not a viable option for some setups. Setting the TYPO3 secret key via .env - fair enough, not a problem. What about passwords, API keys, email addresses etc. entered via the backend Extension Configuration forms though? I don't want any of that in version control and putting it into .env only complicates things a lot because as a developer or integrator I might not even have write access to that file on production.

And if all the secret and environment specific configuration would be in .env/AdditionalConfiguration.php, why would LocalConfiguration.php even be required? The file could be optional or entirely removed if it contained only defaults.

There are more issues with versioning LocalConfiguration.php as stated by @mxsteini like the problem with system maintainer IDs. If changing the DB changes LocalConfiguration.php, shouldn't I version the DB along LocalConfiguration.php then? Or at least the affected table.

Versioning LocalConfiguration.php has caused us nothing but trouble, without any significant gains. I mean, just version a LocalConfiguration.php.dist with all the important non-secret settings and copy that on checkout (can even be done via a git or DDEV hook), or add a shell script which calls typo3cms install:setup with all the required parameters (again, can be done via hook).

[mxsteini]

This would be a great idea.
The behaviour of TYPO3 and Localconfiguration is so annoying.

Here a some more reasons to never put this file in the versioning

1. The file contains security items (keys, database connection and passwords). If your git gets compromissed, your credentials are in the public (as pointed by phosphenius)
2. The file changes "by itself". If you browse in the backend of TYPO3 and open the extension manager, the file is pontentially reformated. The Content doesn't change, but the file would be in your next commit. After checking this changes 10 times a day, one may be that annoyed about this issue, that he might ignore further changes and push accidently some critical changes to the project.
3. The file contains serialized arrays. This data ist nearly unreadable and one have no chance to controll the correctness of the changed values.
4. The file contains maintainer uids. This means for developers, that your local installation must contain the same be-users like the live-system. That is a very difficult issue when your giving your database to your freelancers.
5. For a developer it is tricky to create a maintainer on your local dev-system without changing the git. (OK, if your a real developer, this is not an issue)
6. At least, we have the possibilty in the backend to adjust the LocalConfiguration. This is a really great feature. You can can give your admin-editor the opportunity to change the setup very locally. E.g. additional credentials for foreign databases or temporary debug-options without the need of shell access and poking on the filesystem.

Summary: Versioning LocalConfiguration is like storing a selfchanging BLOB with critical credentials.

If you want to versionise your backend configuration, put that data to AddtionalConfiguration. In addtion with the dotenv-connector you can have great and stable configuration.

[Lefaux]

Not directly related to the proposal here but I'd love to hear your thoughts on this.
Would it be "good" if config that is being set from the backend UI is stored in AdditionalConfiguration.php (if such a file exists)?

It's just a quick thought that crossed my mind and by all means not fleshed out.

[mxsteini]

To be honest. No that's not good. LocalConfiguration.php is a very good place to put the data from the backend UI.
It is good to have this mechanism. Especially for no-composer-people and for non-dev-admin-user.
Again, I find no reason to put LocalConfiguration in the git but many against.
This file contains local configuration (as it is named). Keep it local.
If one wants to config the backend for everyone, use AdditionalConfiguration.php.

In short: All problems from above are solved by remove that line from .gitignore.

[gilbertsoft]

Please see also the discussion in #22. It's absolutely fine like this!

[mxsteini]

@gilbertsoft there's nothing fine like this.
That thread doesn't give any pro reason.
Except "Everyone is doing thing"

[Lefaux]

let me give you an example.

I have a lot of settings that apply to dev, prod and testing.
So, there are things I want the same on all my environments.

There are, however, some settings that I want to be different.
So in my projects, my .env is committed and while it holds "some" arguably sensitive data, none if that really is.

I use DDEV, so I'm fine exposing the DB credentials to the public.
Also my App Secret is actually on github. Because it doesn't matter.
There is, however a couple of things like API keys etc. which are not intended for the public.
These go into .env.local files.
They also differ between dev, prod and test (I don't want to run my tests against a live API, I want them to run against the staging/testing setup.
And my development APIs are a different sandbox again.

I agree that having ONE TYPO3-config file and then loading .env into it feels cumbersome. I think the reason why this is suggested so often is pure human habits.
I use it in Symfony, so this is how I (!) like it.
I'm not trying to convince you of anything. I'm just sharing how I use it so you can make up your own mind how you like it.

So let's talk philosophy for a minute:
It doesn't matter whether you store your settings in an PHP array or a plaintext file like .env.
TYPO3 offers a way "similar" to .env by using the AdditionalConfiguration.php file.

If you put these side by side you can see that they do exactly the same thing.
So if I take my example from above I have LocalConfiguration.php with all non-critical settings and credentials in GIT but an AdditionalConfiguration.php not in GIT.
The truly secret things go into AdditionalConfiguration.php.

That's what the .gitignore does.

And let me stress again: .env is a thing the people that use .env in projects other than TYPO3 are used to. So I can relate that this is how they work.
So my understanding is that the .env folks try to eagerly praise .env to you and your natural reaction is "why the hell would I want that???".
And, if I put on my TYPO3 glasses, I am completely with you. Stick to AdditionalConfiguration.php :)

Does this help out a bit?

[mxsteini]

No, doesn't help.

There is no reason to accept all the problems from above.
You castrate the extension manager and store blob-like, unmaintainable, self-modifying content to your git.

As I take your example from above:

• Put your all-over-settings in AdditionalConfiguraion.php and store them in git
• If you need some specials, add some conidtion or load them by .env.
• Let your admin maintain your API-keys via Extensionmanager or put them in your .env
• And get rid of all the mentiond problems.

Still, I see no technical pros, but many contras.