Don't copy default settings files that are not needed

[shelane]

Is your feature request related to a problem? Please describe.

1. I'm always frustrated when I add a new multisite and the default.global.settings.php (that I have renamed to global.settings.php as per instructions) has reappeared in the site/settings directory.

2. I get notifications for each existing multisite that No /var/www/docroot/sites/default/default.settings.php file found. When the settings.php file for the site already exists when a new site is added, it shouldn't try to add a default.settings.php file.

Describe the solution you'd like

1. Check for the existence of the sites/settings/global.settings.php file and only copy the default file if it does not exist.

2. It should check if the site/settings.php file exists and only issue the warning if it does not.

PR forthcoming.

[danepowell]

I would consider it best practice to leave the default settings files in place and copy them to their "active" versions, rather than renaming them. One practical reason to leave those in place is that it's more obvious when they change, so that you can take a diff and apply relevant changes to your own active versions.

Does leaving default.settings.php and default.global.settings.php in place actually cause any harm, besides a marginal amount of clutter in the directory?

Note that BLT isn't the only way these files can come to exist, I believe Composer Scaffold will also recreate default.settings.php if it doesn't exist, at least by default.

@mikemadison13 do you have any preference on this, as someone who deals with these files in production a lot more than I do?

[shelane]

If that is the recommendation, then wording in the file should be changed:

To use this file, rename to global.settings.php.

[danepowell]

Makes sense, I updated the instructions. Thanks for the report!

[shelane]

It would have been nice to remove the unnecessary warnings that I included in my PR.

[danepowell]

That's fine, I merged and backported it.