Add support for standardized location of settings.local.php on Pantheon

[kreynen]

settings.local.php can't be used to store values that differ on dev, test, live and multisites in code or files without overwritting the file in either code deployments or file synchronizations between instances.

We've placed the settings.local.php in .drush. This can be done in the settings.php after install, but since a check already exists for Pantheon specific settings it seems like the Backdrop way to handle this would be to add an additional check that is Pantheon specific or replace the check in https://github.com/CuBoulder/backdrop-pantheon/blob/master/settings.php#L342 with one that works with Pantheon.

I'm going to create a PR with what we've done, but open to feedback on where the settings.local.php should live and how it should be loaded by settings.php.

[herbdool]

So I guess you're looking for an existing directory in Pantheon that's outside the webroot and won't be wiped on file cloning? I guess .drush is as good as any, but it's not super intuitive. Not sure if that can be helped other than adding a note that people should upload the file in each environment where they want to override.

[kreynen]

Exactly. My plan was to document this as well as how you could alter the location of the active config so in settings.php so that was maintained in code. In the end, a stable Backdrop site might end up with configs in 3 different places managed by different parts of the Pantheon UI.

1. By default, both active and staging are in /files and are cloned between environments and backed up with files. This solves the most critical issue with the current configuration which is you can't get from dev -> test since code/files is in the .gitignore.
2. Once development is complete, I think it makes sense to move the active config into code. Not sure exactly where this would go since we haven't gotten that far yet, but I would like to see a standard defined. We are also looking at the Silkscreen spoon and thinking about how configurations could be split/overridden/managed differently. But moving config into code makes sense on Pantheon if for other reason than the issues with JSON files and the Valhalla file system (@quicksketch and @jenlampton warned us about that and we've experienced it, but I haven't found an open issue about it anywhere).
3. Adding instance-specific settings to .drush (if required). This is only for more advanced use cases like using SAML where the full path to the authentication endpoint is required for the IdP.

[greg-1-anderson]

@kreynen Could you be more specific on what content you want to put in settings.local.php for SAML, and how the code varies by environment? Adding a file on Pantheon that is not in version control and not in the files directory is a bad idea. Any environment may be migrated to a different server at any time; if this happens, only code and files will come along. Your external file would be left behind. Also, $HOME/.drush is not a guaranteed location for you to modify. Pantheon might remove this location or make it non-writable at any time. The same goes for any other location that is not code, files or $HOME/tmp.

(On Pantheon, $HOME is /srv/bindings/BID)

[kreynen]

We aren't using SAML yet, but we needed this for githubapi_sso as well. While we could accomplish the same thing using a check of the environment in the settings.php, this doesn't scale as well with multidev where we'd be modifying the settings.php in code and constantly toggling the state of the .gitignore. Storing the instance-specific values in settings.local.php has worked a lot better for us than a universal setttings.php for all instances with a bunch of if/thens or switches.

[greg-1-anderson]

If the data you need in settings.php varies only by the name of the multidev, then you could use something like:

$myvariable = "mydata" . $_ENV['PANTHEON_ENVIRONMENT'];

This is the preferred solution, when it meets your needs.

If you need more variability and perhaps some credentials, lockr is a good solution, and works with Pantheon.

The scenario that you are describing has the shortfall of needing the site-local settings file refreshed after any migration, and after the creation of any new multidev environment. It can work, but you should use $HOME/tmp instead of $HOME/.drush for this purpose..

[kreynen]

The issue with GtiHub and SAML (the way our IdP is configured) is that the configuration on the service end requires the full URL of the endpoint it will pass the response back to. In our current workflow, when a new multisite is created the values in settings.local.php have to be updated, but the file exists after the instance is created and the directions are pretty straightforward. The fact that the settings.local.php is created on instance instantiation, but node cloned, committed or backed up is actually ideal for our needs.

Last time I looked at /tmp, files created there were not included when a new instance is created. I'll test this again.

The values we are storing in the settings.local.php now are only...

$settings['githubapi_client_id'] = 'xxx';
$settings['githubapi_client_secret'] = 'xxx';

[herbdool]

This seems like a pretty narrow use case then. Since you've got a separate upstream I'd say let's not merge this and leave it to individual sites to move things around if they need to.

[kreynen]

If the need for a settings.local.php is common enough that it's supported by Backdrop in core, why wouldn't the need for that to function on Pantheon also be common?

[jenlampton]

I still use settings.local.php for my sites that are hosted on pantheon.

[greg-1-anderson]

Pantheon does not support the use-case that you requested.

[kreynen]

@jenlampton you use it for your local development environment or on each Pantheon instance?

[jenlampton]

@kreynen I use settings.local.php for local dev settings for sites that are hosted on Pantheon. Maybe I added the code in manually to the settings.php file for each site? I don't recall. I haven't tried to store anything in there that would be needed on Pantheon.

[kreynen]

I'm coming at this from the perspective of needing to configure certain things that are instance/hosting specific. All of our current D7 sites using our install profile use a standard settings.php file with additional setting includes. Every well run Drupal site w/ a re-usable codebase I've worked on added these files to the standard settings.php so it was great to see Backdrop support that out of the box. The local version of the settings are things that aren't intended to transfer with the rest of the code and configuration like the githubapi_sso settings or our local development settings. Because each instance of the site has to have its URL endpoint configured in Github, you can't reuse that part of the config. For Pantheon, the instance-specific needs can live in a switch or if/then clause of the common settings.php that is captured in code or in a settings.local.php that is added to the .gitignore in multisites.

What we did with the githubapi_sso is basically the same thing we've had to do with SAML in D7 when the IdP requires a fully qualified url as an endpoint in the CMS.