After upgrading to Provision version 7.x-3.9 from 6.x-2.4, we found that newly-created websites are now provided with an empty 'local.settings.php' file which is included by the site 'settings.php' file, if present. This isn't a behavior that is useful for our installation, because our users are in the habit of using a pull from a Git repository to supply a 'local.settings.php' file, if needed. This empty file would interfere with our workflow. Thus, I've patched the 'provision/Provision/Config/Drupal/Settings.php' file to suppress the creation of this file if a new Drush variable called 'provision_create_local_settings_file' is set to FALSE. The default behavior of creating the file is left unchanged. Thus, for our installation, we set this variable in the '/var/aegir/.drush/local.drushrc.php' file to FALSE.

CommentFileSizeAuthor
#2 suppress_local_settings_file-issue_#2879243-v1.patch2.6 KBkfolsom
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kfolsom created an issue. See original summary.

kfolsom’s picture

kfolsom CreditAttribution: kfolsom commented
FileSize
suppress_local_settings_file-issue_#2879243-v1.patch2.6 KB
colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented

Looks like this is being handled by #2877650: Site Git Repos? The file name is different, but would that be sufficient?

Feel free to comment on or review what's going on over there. It would be good to finalize that new documentation page.

kfolsom’s picture

kfolsom CreditAttribution: kfolsom commented

Thanks for the response. I read the information at the link you provided. It indicates that the recommended Git repo structure includes a .gitignore file that contains 'local.settings.php', telling Git to ignore this file. But rather than having Git ignore that file, we want it to be in the repo and pulled down by Git. That's why having Provision create an empty 'local.settings.php' file is problematic; if Provision creates this file and a web site maintainer then creates their own within the Git repo, the empty file will get in the way of the user's Git-controlled file. Thus the need for the patch I submitted above, allowing us to set a variable to over-ride the default Provision behavior.

Another option is to change Provision so that it never creates the empty 'local.settings.php' file. I'm not clear on why this is needed or what the use case is for it.

Thanks again,
Keith

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented
Status: Active » Needs review
colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Colan Schwartz Consulting commented
Related issues: +#2877650: Site Git Repos
c_archer’s picture

c_archer CreditAttribution: c_archer as a volunteer and commented

Hi Keith,

I agree not having 'local.settings.php' in Git is frustrating. The way I've got round it without patching is as per https://www.drupal.org/node/2877650#comment-12081846

It does mean I have to SSH in and add the include to 'local.settings.php' which is not ideal. As per your initial comment having an option to turn this off would be useful. Preferably having this is as a tickbox in the UI under admin/hosting/settings or if a site is built from Git then it's disabled.

Thanks,
Chris

kfolsom’s picture

kfolsom CreditAttribution: kfolsom commented

Hi, Chris,

Thanks for the information on how you are handling the 'local.settings.php' file. Our website maintainers don't have access to their site files via SSH, so Git becomes the only way for them to add files or configuration settings to their site. So managing the 'local.settings.php' file via Git is very useful.

Can you explain why Provision is manipulating the 'local.settings.php' file at all, beyond possibly setting proper permissions on it? I haven't been able to understand why it is even being created if not found, given that the created file just contains an opening PHP tag.

I agree that a UI option for configuring this behavior would be ideal, if the behavior is needed at all. I made it a Drush option variable because that seemed simple and sufficient, somewhat analogous to the other existing options such as 'provision_verify_platforms_before_migrate' and 'provision_backup_suffix'.

Thanks again for your feedback,
Keith

memtkmcc’s picture

memtkmcc CreditAttribution: memtkmcc at Omega8.cc commented

Here is some background on why and when it was introduced:

#1066000: Local.settings.php can stop working due to file ownership/permissions

helmo’s picture

helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions for Aegir Cooperative commented
Status: Needs review » Reviewed & tested by the community

Thanks, the patch looks sane.

Creating the file was mainly done to help users discover the possibilities of it, but I can see how it gets in the way when you don't ignore it in Git.

Patches for UI elements are welcome.

helmo’s picture

helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions for Aegir Cooperative commented
Status: Reviewed & tested by the community » Fixed

  • helmo committed c113ad6 on 7.x-3.x authored by kfolsom 
    Issue #2879243 by kfolsom: Suppressing Creation of a Site 'local....

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.