Ignore web/sites/*/settings.php

[ceefour]

No description provided.

[normanlolx]

Maybe web/sites/*/settings.local.php can be ignored in advance as well?

[ceefour]

@leymannx done

[PatrickBauer]

I understand the idea to ignore the settings.local.php, but not the settings.php file.

In our case, we're using the settings.php file for project-specific settings which should be shared between all developers and the settings.local.php for database-settings and developer specific settings. The server itself has a settings.local.php file too, so no sensitive information gets shared.

[normanlolx]

@PatrickBauer Ah I think now I do understand how it's intended to be used: You completely remove the database-relevant part from settings.php and only have it inside the (ignored) local.settings.php files. Can you confirm that?

[PatrickBauer]

@leymannx I don't know if its intended to be used that way, but yes, thats how we handle it at our company.

[ceefour]

@PatrickBauer I don't think that's the "official" way of doing it. Since Drupal installer writes to settings.php, not settings.local.php (CMIIW).

Note that each company can still force-checkin settings.php even if ignored, so this PR won't prevent your company from doing what you've been doing. But it makes everyone else safer by default.

[webflo]

I always commit settings.php without any security related settings (db connection, hash salt) to my repo and enable the include of settings.local.php. Every environment specific settings goes to settings.local.php

[derhasi]

Drupal itself has it listed in its .example.gitignore. But I think this really depends on how you deploy and host your project and therefore is very opinionated.

For the short term, adding it to .gitignore might make it more secure for less-experienced users. For the long term, I am currently not sure if and how we should support different approaches within this project. Maybe some sort of scaffolding-tool/installer could assist in the future, but that would have to be maintained too.

[derhasi]

Note that each company can still force-checkin settings.php even if ignored

@ceefour, that is no good idea in terms of making your git-repo and process comprehensible. In such a case you really should remove the line from your gitignore.

[ceefour]

@derhasi that's why we have fork in git.
The goal is to give sane defaults. If everyone else wants to custom it (not just gitignore, but anything) they can. Just not the default.

What I mean is everybody has their own version of gitignore anyway, I may want to ignore my IDE's files and whatever. But the files that are part of Drupal stuff, should be handled by default.

[normanlolx]

Although I totally understand @ceefour as well, I tend to vote for "won't fix" and a line about the suggested procedure (to move db info and hash salt into local.settings) in README so others learn it as well. This seems like the most convenient solution to me.

[Kazanir]

I would also move for won't-fix -- at Platform.sh the methodology we encourage and which everyone seems to use is to commit a settings.php file with project-wide settings and add environment-specific settings to an omitted settings.local.php file. The fact that Drupal's default gitignore file still includes settings.php is more or less an artifact of an earlier age.

[daften]

My 2 cents
The way this project works should not be based on whatever method any cloud provider uses. It should be based on what Drupal ships with and expects. And that is still that settings.php should be excluded. Making new assumptions here will only work confusing. I would propose to actually ignore settings.php by default. Anybody that wants to use this methodology with a settings.local.php can then use it, but will have to adapt the .gitignore file themselves, which shouldn't be a problem.
Basically, agreed with @ceefour

[ostark]

I agree with @Kazanir - in git/composer based applications ENV var configs are very common.

http://symfony.com/blog/new-in-symfony-3-2-runtime-environment-variables
https://laravel.com/docs/5.3/configuration#environment-configuration

I would love to see this in Drupal as well, especially in drupal-composer.

[gagarine]

This is a huge security risk especially because drupal installers write directly in settings.php. Please use safe defaults, advance users can always customise to their needs.

I have years of experiences with drupal and git and yet I almost committed the settings.php because in any projects (symfony, drupal, ...) settings are ignored because they can contain highly sensitive information.

This also makes this project look unprofessional :/ and I think it should be removed from the DO documentation until this is fixed.

[wimleers]

The way this project works should not be based on whatever method any cloud provider uses. It should be based on what Drupal ships with and expects. And that is still that settings.php should be excluded. Making new assumptions here will only work confusing. I would propose to actually ignore settings.php by default. Anybody that wants to use this methodology with a settings.local.php can then use it, but will have to adapt the .gitignore file themselves, which shouldn't be a problem.

+1

If this wants to deviate from that, then it should be documented super explicitly.

P.S.: When this project is used to deploy Drupal 8 on gandi.net's "Simple Hosting", then this results in your settings.php being overwritten.

[derhasi]

@webflo @greg-1-anderson I am pro merging this. Do you have any other opinion on this?

[greg-1-anderson]

I prefer to commit settings.php as well, and Pantheon expects this. I do wish that Drupal did not write the database credentials to settings.php during the installer by default, but it does. In the balance, setting personal preferences aside, I think that following the example.gitignore file in core is the right thing to do.

[webflo]

Thanks you all. I think the installer should write the credentials and hash key to settings.local.php. Maybe we could create a command that moves this stuff around? I will explore some options soonish.