As part of #2354475: [meta] Refactor the installer, (multi)site management, and pre-container bootstrap, we want to get rid of all or most of the singletons (, and a lot of the procedural code with global state).
We want to have regular objects that can be managed in the CoreContainer, and only keep static method access for BC.

One such singleton is \Drupal\Core\Site\Settings.
It is important for pre-container bootstrap, and we definitely want to make it a service in the CoreContainer.

The general strategy there is:
1. Split the singleton instance into a separate class, for a better separation of concerns.
2. Make it possible to freely instantiate it independently of the singleton instance variable (e.g. for unit tests).
3. Let the CoreContainer handle the (lazy) instantiation, and the dependencies needed for that.
4. Initialize the static instance variable with the instance from the container, for backwards compatibility.

Other issues to watch out for:
#2306013: Multisite is a valued feature that will not be deprecated.
#1757536: Move settings.php to /settings directory, fold sites.php into settings.php

Comments

donquixote’s picture

donquixote commented

A current problem are the globals in Settings::initialize(), the $database variable, and the static call to Database::setMultipleConnectionInfo().
Having this call in the same method that includes the settings.php is a mix of concerns that should be separate.

final class Settings {
  [..]
  public static function initialize($site_path, &$class_loader) {
    // Export these settings.php variables to the global namespace.
    global $base_url, $cookie_domain, $config_directories, $config;
    $settings = array();
    $config = array();
    $databases = array();

    // Make conf_path() available as local variable in settings.php.
    if (is_readable(DRUPAL_ROOT . '/' . $site_path . '/settings.php')) {
      require DRUPAL_ROOT . '/' . $site_path . '/settings.php';
    }

    // Initialize Database.
    Database::setMultipleConnectionInfo($databases);

    // Initialize Settings.
    new Settings($settings);
  }

I would like to turn all of these into local variables, which then become part of the return value.

class SettingsFileReader {
  [..]
  public function readFromFile($site_path, $class_loader) {
    // Declare some variables to be overwritten in settings.php.
    // Some of these will later be exported as globals.
    $base_url = NULL;
    $cookie_domain = NULL;
    $config_directories = NULL;
    $settings = array();
    $config = array();
    $databases = array();

    // Make $site_path available as local variable in settings.php.
    if (is_readable(DRUPAL_ROOT . '/' . $site_path . '/settings.php')) {
      require DRUPAL_ROOT . '/' . $site_path . '/settings.php';
    }

    return new SiteSettings(
      $settings,
      array(
        'base_url' => $base_url,
        'cookie_domain' => $cookie_domain,
        'config_directories' => $config_directories,
        'config' => $config,
        'databases' => $databases,
      ));
  }

Then there could be sth like $siteSettings->exportGlobals(), and $siteSettings->getDatabases().

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.

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

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

kingdutch’s picture

kingdutch
he/him
Primary language English
commented
Assigned: donquixote » Unassigned
Status: Postponed (maintainer needs more info) » Active

This issue is still relevant. It's part of a larger set of issues around core Drupal classes having too many responsibilities.

One discussion was around "Drupal Application Context" highlighted here: https://www.drupal.org/project/drupal/issues/2529170#comment-16075215

Similarly the ongoing discussion about the many things that the DrupalKernel is doing: https://www.drupal.org/project/drupal/issues/2282779

As donquixote outlined in the issue summary and the first comment, the Settings class currently isn't just a read-only container of settings. However, it's also responsible for loading those settings depending on the current site and even setting up the database configuration.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.