[regression] With Drupal 9.4, can no longer call Database::getConnection() from within settings.php due to driver classes not yet in autoloader

perhaps something like moving the current Settings::initialize() code for setting up the autoloader into Database::getConnection() might solve it?

I didn't like the sound of this when I read the sentence, but the patch itself looks pretty good to me.

The patch from comment #15 looks very good to me. Just 2 nitpicks:

1. +++ b/core/lib/Drupal/Core/Database/Database.php
   @@ -324,11 +376,17 @@ final public static function getAllConnectionInfo() {
   +    if (!$class_loader) {
   +      $class_loader = self::getClassLoader();
   +    }
   

   We are already doing this in addConnectionInfo(), do we remove it here?

2. +++ b/core/lib/Drupal/Core/Database/Database.php
   @@ -701,4 +759,23 @@ private static function isWithinModuleNamespace(string $namespace) {
   +    $additional_class_loader = new ClassLoader();
   +    $additional_class_loader->register(TRUE);
   

   The function Database::convertDbUrlToConnectionInfo() also has the same code. Can we replace that code with self::getClassLoader()?

The patch from comment #17 looks to me like as we should do the class loader stuff in a saperate issue and after that is done, fix the problem from this issue. Also there are a couple more instances in DRUPAL_ROOT\core\lib where we have code like new ClassLoader().

@effulgentsia: As you are working on this issue and you are core framework manager, I leave it up to you which route we should to take (the patch from comment #15 or the one from comment #17). My preference is the one from comment #15.

I was trying to update my 9.3.x to 9.4.1 and I believe I'm affected by this regression. My site is built with composer, using the drupal/recommended-project.

My symptoms:

• After updating to 9.4.1, I do not have a connection to the database and I get redirected to core/install.php
• If I say drush status, I see I don't have a connection to the database, which explains the redirect to core/install.php

I read through all comments above and looked at some of the patches of this issue.

Patch #5 has this inline comment:

// Backwards compatibility layer for Drupal 8 style database connection
// arrays. Those have the wrong 'namespace' key set, or not set at all
// for core supported database drivers.

I believe I have this Drupal 8 style database connection array, since my site originates from the early Drupal 8 versions.

My database array in settings.php was this, and it indeed has the 'namespace' element that the inline comment quoted above talks about.

$databases['default']['default'] = array (
   'database' => getenv('DRUPAL_DATABASE_NAME'),
   'username' => getenv('DRUPAL_DATABASE_USERNAME'),
   'password' => getenv('DRUPAL_DATABASE_PASSWORD'),
   'prefix' => '',
   'host' => getenv('DRUPAL_DATABASE_HOST'),
   'port' => '3306',
   'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
   'driver' => 'mysql',
);

However, even if I try to update it to this, what is currently present in the 9.4.x default.settings.php, my issue persists:

$databases['default']['default'] = [
  'database' => getenv('DRUPAL_DATABASE_NAME'),
  'username' => getenv('DRUPAL_DATABASE_USERNAME'),
  'password' => getenv('DRUPAL_DATABASE_PASSWORD'),
  'host' => getenv('DRUPAL_DATABASE_HOST'),
  'port' => '3306',
  'driver' => 'mysql',
  'prefix' => '',
  'collation' => 'utf8mb4_general_ci',
];

I'd like to update my settings.php to be of the current style, but I can't see any other difference in the $databases array than that the 'namespace' has been removed and 'collation' has been added.

I understand the discussion above about the workarounds, but I guess the more elegant approach for me and other sites from the early D8 days would be to modify the settings.php to reflect what it currently needs to be, it's just that I don't spot what other aspects I'm missing... Any hints would be appreciated!

Cheers,
Markus

p.s. I do not want to de-rail the scope of this issue. The reason why I'm posting this comment here is that this specific issue is linked from the 9.4.0 release notes, which I did read. And I'm posting this comment here so that other community members who read the release notes would find this as well.

Edit: Added the link to 9.4.x default.settings.php

Okay, figured it out. Writing here for others that might be affected by the same things.

It turned out that I had two separate issues:

1. I was affected by the Composer July Timebomb. The 'allow-plugins' section needs to be added to composer.json, see
https://github.com/drupal/recommended-project/blob/9.4.x/composer.json#L32

2. After I added that and removed the old 'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql' from the $databases array in settings.php, my site was back to normal and I was able to complete the 9.4.x updates.

Hope this helps if somebody else is affected in the same way that I was.

Cheers,
Markus

Add postponed issue to the IS>

Acquia Cloud is one example where code like the above in settings.php (or rather, a .inc file included by settings.php) is done.

We are affected by this too on Acquia environments:

On drush cr:

Fatal error: Uncaught Error: Cannot instantiate abstract class Drupal\Core\Database\Query\Upsert in /core/lib/Drupal/Core/Database/Connection.php:1312

On drush status:

Cannot instantiate abstract class Drupal\Core\Database\Schema

The recommended workaround on Acquia (only for dev/staging) is to set databases classes namespace in settings.(acquia.)php:

if (file_exists('/var/www/site-php')) {
  // Workaround for database error:
  // Cannot instantiate abstract class Drupal\Core\Database\Schema.
  $class_loader->addPsr4('Drupal\\mysql\\', DRUPAL_ROOT . '/core/modules/mysql/src/');
  // Load database and other configuration.
  require '/var/www/site-php/PROJ_KEY/PROJ_KEY-settings.inc';
}

We noticed the error when upgrading from 9.4.7 to 9.4.8. The workaround does fix the issue.

We are also on Acquia.

@vlad.dancer

The recommended workaround on Acquia (only for dev/staging)

Why only for dev and staging? Why not prod?

Acquia's article has been updated to read "this workaround should be tested on lower environments (dev or stage) before applying to a production environment."