Replace global $config with a property on the Settings singleton

Here's a patch that removes the global $config by adding it to the Settings object which I think makes sense since this object corresponds to settings.php and is a singleton already.

Actually I don't think this needs a change record. Existing contrib should not be setting the global. I'd be surprised if even using this in tests was common.

+++ b/core/core.services.yml
@@ -229,7 +229,7 @@ services:
       - { name: event_subscriber }
       - { name: service_collector, tag: 'config.factory.override', call: addOverride }
-    arguments: ['@config.storage', '@event_dispatcher', '@config.typed']
+    arguments: ['@config.storage', '@event_dispatcher', '@config.typed', '@settings']
   config.installer:

That's actually the opposite of what we're doing in #2443351: Ensure that settings can't be serialized by not injecting them / replace stuff with container parameters..

1. +++ b/core/lib/Drupal/Core/Site/Settings.php
   @@ -86,6 +94,23 @@ public static function get($name, $default = NULL) {
   +
   +  public static function hasConfigOverride($name) {
   

   Needs some quick docs, but the name describes things really well already.

2. +++ b/core/lib/Drupal/Core/Site/Settings.php
   @@ -86,6 +94,23 @@ public static function get($name, $default = NULL) {
   +    return array_key_exists($name, self::$instance->configOverrides);
   

   Is there a reason you used ake() instead of the isset() calls in other current code?

3. +++ b/core/modules/config/src/Tests/ConfigEventsTest.php
   @@ -64,8 +65,10 @@ function testConfigEvents() {
   +    $overrides = Settings::getConfigOverrides();
   ...
   +    new Settings(Settings::getAll(), $overrides);
   

   Does that mean for consisteny we should have Settings::getAllConfigOverrides() ?

1. Fixed see 2
2. I was overcomplicating this by thinking about being able to NULL config values - but that does not apply here since we working on the config object name level
3. Fixed

Re #8 I'm not sure that that issue will pass our beta evaluation.

Patch requires re- roll -- setting to needs work.

Just some minor adjustment

I am wondering if I change username/password of my db in settings.php, I see "The website encountered an unexpected error. Please try again later." error not "PDOException".

Well, we hide exceptions by default. It is as simple as that, but we provide tools (see settings.local.php) to show the entire exception.

Unfortunately we can no longer change this safely in 8.x, so postponing to 9.x per discussion with cilefen and alexpott.

What about a BC layer?

I'm not sure a BC layer is possible because with a global anything can add to it at any point - yes it is fragile but if you set a config override before that specific configuration object has been loaded then it'd work. :( globals--

I don't think #18 constitutes an API break, so moving this back to a minor version for now.

We could also add support for a new key, that's not a global, and deprecate $config.

I was thinking that we could make global access to $config and $config_directories @internal and document that the only supported way of setting these is in settings.php.

#2550249-45: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation proposing we make #21 part of the docs.

I think that that means we need a getter for global $config so that as long as code is using the getter and setting them in settings.php then their code will not break.

Something like this. I think it is important that the new getter is used somewhere to (a) prove it works and (b) prove we don't break it. Hence I've used in the ConfigFactory - the most important place. But instead of forcing the injection of Settings I've made it optional - which i think is okay because it is a global singleton itself. This buys us testability and the ability remove the global $config in the Drupal 8 cycle. I've also made the other config global @internal because it already has a getter.

Mh, so does that mean we can use the global at some point just for setting and unset it later?

It means the only supported way of setting it is in settings.php where you all you have to do is $config['blah'] = ...

This way no one has to interact with the global at all.

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 200, following Review a patch or merge require as a guide.

Tagging for an updated issue summary after 7 years imagine a lot has changed. Would be good to see what's still all needed (if anything).