One of the problems with upgrading a Drupal site between point releases is if default.settings.php is changed. Users most likely never update their local settings.php and may not know about new features or bug fixes. Especially for new users of Drupal, the only modification from the default settings file is the database connection. My suggestion is that a Drupal /sites directory should look something like this:

default/settings.php
default.settings.php
common.settings.php
  • default.settings.php would be identical in content to what we have, but actually be sourced for configuration. It would be the first file included.
  • common.settings.php as would store settings common to all sites. Core would just ship a file with comments indicating it's purpose. It would be included second, and could override any variable or ini_set() just be redefining it.
  • Finally, default/settings.php would only initially contain settings created by the installer. In most Drupal sites, this would probably end up being the configuration and any private keys.

Thoughts?

Comments

mlncn’s picture

mlncn commented
Issue tags: +SettingsAPI

+1

grendzy’s picture

grendzy commented

+1 for common.settings.php. I would also like a default/local_settings.php, which would be local overrides used for configuration that differs between servers (for example reverse_proxy might be TRUE on production but FALSE on a development box).

Regarding default.settings.php, I can see a couple of concerns. 1), the name "default" might cause users to confuse it with the "default" site, when in fact it would apply to all sites. How about core.settings.php? 2) If this is a file packaged with core, are users allowed to "hack" it? If yes, that brings us back to the pain of D5 where every point release update overwrote our settings file. If no, then why put it here at all? Why not set essential defaults in bootstrap.inc?

For new features / bug fixes incorporated into default.settings.php, it would help if you can provide some historical examples. How often has this happened in our project's history?

traviscarden’s picture

traviscarden commented
Title: Move to a inherit and override model for settings.php » Move to an inherit-and-override model for settings.php
Issue tags: +settings.php

However it's accomplished, I would love to see, if you will, an object-oriented approach to settings such that you have a main site configuration and modify in variants only the things that are different. I have a site with over five different environments for development, testing, and staging, and all of them have a few things in common (like variable overrides, cache includes, etc.) but each one connects to a different database. Nevertheless, I have to re-specify all the common elements in every settings.php, which violates the DRY principle and causes all the usual problems.

deviantintegral’s picture

deviantintegral commented

For now, use an include file for settings common across multiple sites. Works very well for settings like string overrides that nearly always should be shared.

traviscarden’s picture

traviscarden commented

Thank you, @deviantintegral, that's a good workaround. (Why didn't I think of it?)

hackwater’s picture

hackwater commented

We like to include the settings file in all our settings.php files (we run multi-site), keeping the actual settings.php file pretty bare-bones and site-specific. If default.settings.php should change, those changes are automatically incorporated unless we've overridden them in the specific site.

We also include common settings (we store those in sites/) for things like external DBs (so a Drupal-style $database array entry for a DB all sites should be able to switch to and read from).

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Issue summary: View changes
Status: Active » Closed (works as designed)

@deviantintegral, thanks for the suggestion!

The proposal doesn't met the Criteria for evaluating proposed changes. In this case, there is not demonstrated demand and support for the change.

Cheers