FIx settings.local.php after new bootstrap

Why is $conf_path no longer defined when settings.php is read-in?

That sounds like a major bug.

Nevertheless, changing this to use __DIR__ would be fine either way.

I like this, __DIR__ is always preferable if we know that it has to be in the same directory.
Even if the $conf_path variable DID exist, I would still prefer __DIR__.

rtbc from me.
Unless you want more feedback from others?

We definitely need to figure out what happened to the $conf_path variable. It should be set in the local scope and be available when settings.php is loaded.

what happened to the $conf_path variable.

It was renamed to $site_path.

Old code in drupal_settings_initialize(), removed in #2016629:

-function drupal_settings_initialize() {
-  // Export these settings.php variables to the global namespace.
-  global $base_url, $cookie_domain, $config_directories, $config;
-  $databases = array();
-  $settings = array();
-  $config = array();
-
-  // Make conf_path() available as local variable in settings.php.
-  $conf_path = conf_path();
-  if (is_readable(DRUPAL_ROOT . '/' . $conf_path . '/settings.php')) {
-    require DRUPAL_ROOT . '/' . $conf_path . '/settings.php';
-  }

New code in DrupalKernel::initialize(), added in #2016629:

+  public static function initialize($site_path) {
+    // 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';
+    }

the $conf_path variable. It should be set in the local scope and be available when settings.php is loaded.

Do we need it there? What would be a use case?
And would it be ok if people have to type $site_path instead? Imo, $site_path is even more logical..

My bad, but that's definitely better any ways. Leaking the implementation of the method into the include makes re-factoring like this harder.

Committed eb3e786 and pushed to 8.x. Thanks!