DISCUSSION: Streamline configuration of settings.php

I'm noticing a pattern in a team I work with and that I'm trying to get on Vlad; Vlad is so easy that they forget about the specific "last-mile" site configuration that we need, e.g. local.settings.php or similar for Pantheon.

That said, I'm wondering if we could build a template into Vlad that would generate a settings.php file and include basic configuration. I wanted to discuss the idea first.

My basic thoughts are:

This would be turned off by default.
Config-wise:

# Whether to generate settings.local.php or not. Doing so can be useful if you're on a provider, such as Pantheon or Acquia Cloud, that expects you to commit settings.php to your codebase.
vlad_generate_local_settings: false

# The name of the local settings file to generate.
vlad_local_settings_filename: settings.local.php

# Whether Vlad should continue to keep the local settings file updated. Leave this false to have Vlad only generate a local settings file when one does not already exist.
# NOTE: Having this on will overwrite any changes you make when you run `vagrant provision`!
vlad_manage_local_settings: false

# If you would like to use a custom local settings template for this site, enter the path to an Ansible template that can be used to generate the file. It's recommended that you copy <THE DEFAULT LOCAL SETTINGS TEMPLATE> and tweak it to your needs.
vlad_local_settings_template_path: ''

I chose settings.local.php as the default because IIRC this is the pattern that the core .gitignore uses to ignore all settings files.

When Vlad manages the settings file, it would simply include database information. I figure we can probably just generate $db_url AND $databases (in that order), such that Drupal 6 and 7 pick up the one they understand. Drupal 8 looks like it works with Drupal 7's syntax as well.

A future idea is another parameter where they specify the Drupal version and we generate a settings file appropriate for it. But the main objective of this feature is to require less of end users and let the ones who know how to set up the site package it up more easily for the rest.

Interested in your thoughts. It's kind of a feature request in that I don't know if I'll be developing it soon, just noticed the need.

Thanks for raising this and for taking the time to consider it and illustrate how you think it might work. It's crossed my mind sooooo many times.

Points for consideration:

It's a really opinionated area, and in general Vlad has tried to avoid those. That said, I hear that you're making every effort to make this an opt-in convenience for users that are happy to let Vlad have an opinion if it saves them time & effort.
Normally I include or require the local settings from within settings.php, automating this would involve knowing things such as the name of the local settings file (which you have covered) and also begins to get complicated in that Vlad would then need to manage settings.php through lineinfile or similar. Not impossible, just a slight can of worms. I notice that you're not suggesting this, is that because of the file name you've chosen for your local settings file and Drupal's settings discovery (if so we'd have to be very clear about filenaming convention for this to work)?
We'd need to consider how this would fit in with drush make especially if users use the --prepare-install option which creates a settings.php file when building out the codebase and drush site-install which then adds database connection details to that settings file.

Overall I'm up for pursuing this, providing it works with Drupal 6, 7 & 8, is opt-in and doesn't clang into any other functionality. @philipnorton42 ?

Re. inclusion, in my mind that's on the user. This idea is only for local settings, and we only ask for the filename so we can template to it.

They could use it on non-platform-driven sites to make a settings.php, sure, but that's not the primary use case. It's a complement of sorts to Pantheon import :)

okt. 2015 13:34 skrev "Dan Bohea" notifications@github.com:

Thanks for raising this and for taking the time to consider it and illustrate how you think it might work. It's crossed my mind sooooo many times.

Points for consideration:

It's a really opinionated area, and in general Vlad has tried to avoid those. That said, I hear that you're making every effort to make this an opt-in convenience for users that are happy to let Vlad have an opinion if it saves them time & effort.

Normally I include or require the local settings from within settings.php, automating this would involve knowing things such as the name of the local settings file (which you have covered) and also begins to get complicated in that Vlad would then need to manage settings.php through lineinfile or similar. Not impossible, just a slight can of worms. I notice that you're not suggesting this, is that because of the file name you've chosen for your local settings file and Drupal's settings discovery (if so we'd have to be very clear about filenaming convention for this to work)?

We'd need to consider how this would fit in with drush make especially if users use the --prepare-install option which creates a settings.php file when building out the codebase and drush site-install which then adds database connection details to that settings file.

Overall I'm up for pursuing this, providing it works with Drupal 6, 7 & 8, is opt-in and doesn't clang into any other functionality. @philipnorton42 https://github.com/philipnorton42 ?

— Reply to this email directly or view it on GitHub https://github.com/hashbangcode/vlad/issues/293#issuecomment-150792219.

As another example, our shop runs both a settings.local.php and a custom vlad.settings.local.php, both included in our standard settings.php with the vlad one at a lower priority. This is because we some legacy sites deployed on a BOA system where checking a settings.local.php file in is required to manage some site and platform features - so we can't use it for vlad settings.

Having said that, it'd be really nice if vlad would generate an appropriate vlad.settings.local.php (or whatever it ends up being called) on provision, because as it stands we end up checking an "example" vlad settings file into our repos and people constantly forget that they have to make a copy without the example bit when they're cloning a project to start working on it.

hashbangcode / vlad

DISCUSSION: Streamline configuration of settings.php #293