-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LocalConfiguration.php is excluded in .gitignore #49
Comments
This would be a great idea. Here a some more reasons to never put this file in the versioning
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. |
Not directly related to the proposal here but I'd love to hear your thoughts on this. It's just a quick thought that crossed my mind and by all means not fleshed out. |
To be honest. No that's not good. LocalConfiguration.php is a very good place to put the data from the backend UI. In short: All problems from above are solved by remove that line from .gitignore. |
Please see also the discussion in #22. It's absolutely fine like this! |
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 |
@gilbertsoft there's nothing fine like this. |
let me give you an example. I have a lot of settings that apply to dev, prod and testing. There are, however, some settings that I want to be different. I use DDEV, so I'm fine exposing the DB credentials to the public. 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. So let's talk philosophy for a minute: If you put these side by side you can see that they do exactly the same thing. 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. Does this help out a bit? |
No, doesn't help. There is no reason to accept all the problems from above. As I take your example from above:
Still, I see no technical pros, but many contras. |
The
.gitignore
file contains the following pattern which allows tracking theLocalConfiguration.php
file in version control:Shouldn't the
LocalConfiguration.php
be excluded from version control though as it contains sensitive data and also contains different content for different hosts/systems? There are even more issues with versioning this file like the problem with system maintainer user IDs.The text was updated successfully, but these errors were encountered: