Respect settings.php where it exists (if ddev didn't create it)

[rfay]

What happened (or feature request):

For Drupal sites, we currently

1. Overwrite the settings.php if it exists
2. With a settings.php which includes settings.local.php

This seems problematic because many sites actually check the settings.php deliberately into code (without sensitive details, which go in settings.local.php or equivalent). So we could "help" a dev to introduce an unwanted change, or break a site by removing key standard settings that are intentional in checked-in settings.php.

Also, the fact that our override-settings.php includes settings.local.php could mean that we don't accomplish what we want anyway, as the settings.local.php might override what we do.

We also may want to include content in an overridden settings.php which identifies it as generated (when we've generated one in an import). That would let us remove it if we knew that we were the source of it. That does not solve the problem of when Drupal creates a settings.php on install.

What you expected to happen:

Codebase provided by the developer should not be altered.

How to reproduce it (as minimally and precisely as possible):

Create a drupal dev site using a repo that already has a settings.php.

Anything else do we need to know:

Related source links or issues (like source JIRA issue):

[rickmanelius]

I missed the initial conversation, but I definitely want to weigh in on this. Assigning to myself so I can catch in my filter.

[tannerjfco]

This behavior is changed in #123 on the import-db command. The command will now only write the settings file if it doesn't already exist, and the user will be notified whether or not a config file was written.

[rfay]

So @tannerjfco this is totally resolved in #123 right? So can be closed?

[tannerjfco]

I believe the major concerns addressed here are resolved with the behavior change i described in #123. If we're good with that this can be closed.

[rfay]

Closing for now then.