drush si is creating a redundant database array in settings.php

[rpkoller]

i finally was able to narrow the issue down. for quite a while the end of the settings.php file in my sandbox project looked like this after a while:

$databases['default']['default'] = array (
  'database' => 'db',
  'username' => 'db',
  'password' => 'db',
  'prefix' => '',
  'host' => 'db',
  'port' => 3306,
  'isolation_level' => 'READ COMMITTED',
  'driver' => 'mysql',
  'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
  'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
);
$settings['config_sync_directory'] = 'sites/default/files/config_d0uPupMsVXU948BjkhMUcNCIzABrcJNG3z-eAKCaFPlbsxucliPUiYTOS9kAlmtPW1cKU_MEYw/sync';
$databases['default']['default'] = array (
  'database' => 'db',
  'username' => 'db',
  'password' => 'db',
  'prefix' => '',
  'host' => 'db',
  'port' => 3306,
  'isolation_level' => 'READ COMMITTED',
  'driver' => 'mysql',
  'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
  'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
);
$databases['default']['default'] = array (
  'database' => 'db',
  'username' => 'db',
  'password' => 'db',
  'prefix' => '',
  'host' => 'db',
  'port' => 3306,
  'isolation_level' => 'READ COMMITTED',
  'driver' => 'mysql',
  'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
  'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
);
$databases['default']['default'] = array (
  'database' => 'db',
  'username' => 'db',
  'password' => 'db',
  'prefix' => '',
  'host' => 'db',
  'port' => 3306,
  'isolation_level' => 'READ COMMITTED',
  'driver' => 'mysql',
  'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
  'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
);
$databases['default']['default'] = array (
  'database' => 'db',
  'username' => 'db',
  'password' => 'db',
  'prefix' => '',
  'host' => 'db',
  'port' => 3306,
  'isolation_level' => 'READ COMMITTED',
  'driver' => 'mysql',
  'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
  'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
);

took me a while to figure it out. but point is that from time to time i'Ve dropped my database with ddev drush sql:drop and then reinstalled the site with ddev drush si. on the regular recommended-project nothing happens and nothing is getting added to the settings.php file. but on the drupal-core-development-project composer template

$databases['default']['default'] = array (
  'database' => 'db',
  'username' => 'db',
  'password' => 'db',
  'prefix' => '',
  'host' => 'db',
  'port' => 3306,
  'isolation_level' => 'READ COMMITTED',
  'driver' => 'mysql',
  'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
  'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
);
$settings['config_sync_directory'] = 'sites/default/files/config_d0uPupMsVXU948BjkhMUcNCIzABrcJNG3z-eAKCaFPlbsxucliPUiYTOS9kAlmtPW1cKU_MEYw/sync';

is getting added. if you drop the database and reinstall the site the path in the config_sync_directory settings line is getting updated while the snippet for the databases array gets readded. that way over time those snippets are piling up and spamming the settings.php. but not sure yet what is causing that behavior.

[rpkoller]

just got reminded to this issue again. any idea what might be causing this behavior? in the current code in this repo i am unable to find any clues pointing towards drush site install that might induce that describe behavior?

[joachim-n]

I think the first thing to do is find the code that's doing the writing to that file.

I don't see anything in SiteInstallCommands that's doing it though. I think it's probably this call to core that does it:

            drush_op('install_drupal', $this->autoloader, $settings, [$this, 'taskCallback']);

so try debugging from here?

[rpkoller]

ahhh thanks for the pointer. will see if i am able to run two xdebug instances alongside so i am able to compare on project with the standard profile and one withi your composer template. maybe i am able to find some clues. was unaware that you only need to add the --xdebug flag to the drush command aside starting xdebug and setting a breakpoint.

[rpkoller]

i managed to get xdebug working in two projects in parallel. one is with your template the other with ddev composer create-project drupal/recommended-project:main-dev@dev && ddev composer require drush/drush. the breakpoint was set to the drush_op line you pointed towards. a few observations about potential noteworthy differences oin the first step

$db_spec in your template
contains ìsolation_level = "READ COMMITTED"
and within the init_commands array with `isolation_level "SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED"

both are missing on the recommended project main branch. but the stp that is responsible for adding to the settings.php file is tiresome to find. with one click step over i get directly past the addition cuz the site install runs through. if i step in it take dozens or hundreds of clicks. will see if i can step into to it.

[rpkoller]

Ok I might have some lead. aside the breakpoint in SiteInstallCommands.php (line 174) i've added several within install.core.inc within the function ìnstall_run_tasks in line 574... after the ìnstall_verification_reqruiements task was performed i've noticed within the $install_state array within the drupal-core-development-project template i have

config verified false
database verified true
settings verified false

while in the main branch i get:

config verified true
database verified true
settings verified true

and line 586 then triggers the addition to the settings.php $output = install_run_task($task, $install_state); not sure if that helps provides you with any clues. is definitely way past my knowledge level in regard of (drupal) code.

[joachim-n]

That sounds like you're getting close!

Based on what you've found, my hunch is that something in Drupal core is trying to detect whether something exists, and because of the core symlink, is finding that it does not. It's then deciding that a whole new $database array needs to be created because of this conclusion.

Then, something else -- maybe Drush? -- which does know the right place to find settings.php -- is doing the writing, and appending to what's there.

[rpkoller]

i guess i might know the problem that causes config_verified and settings_verified to get false. within ìnstall.core.inc settings_verified gets false because config_verified is already false:

  $install_state['settings_verified'] = $install_state['config_verified'] && $install_state['database_verified'] && (bool) Settings::get('hash_salt', FALSE);

and the crux from my limited understanding might be this check config_verified = file_exists($sync_directory). a quick search on the web showed tha file_existsdoesnt work with symlinked files. so core would have to use a function that would work for files as well as symlinked files? which would be an appropriate replacement in php to use instead of file_exists to test locally if it woulld fix the issue?

update: or is file_exists even able to but it is a permissions/webserver config issue according to https://bugs.php.net/bug.php?id=48535 ? i am just collecting clues.

[joachim-n]

I might be wrong about my previous comment.

The code that actually writes to the settings.php file is in SettingsEditor.php. This is tokenising the PHP code in the existing file and adding to it.

It's seeing the existing file -- but I don't understand why the tokenising process would react differently.

If you still have both flavours of installation side by side, I would recommend doing a dump() of token_get_all($contents) and a diff to see if there's anything that stands out.

[rpkoller]

i still have both and i can try and take a look. but looking at the recent outcomes i still think the condition why the settings are written is set in installation.core.inc. within the try in line 389 i'Ve experimented a bit.

on the main branch (not your template)

echo file_exists($sync_directory);
echo realpath($sync_directory);

resulted in (added a few new lines manually)

1
/var/www/html/web/sites/default/files/sync 
[notice] Starting Drupal installation. This takes a while.
1
/var/www/html/web/sites/default/files/sync
[notice] Performed install task: install_select_language

with a more granular snippet (that i use on the project using your template as well afterwards)

    if ( is_link($sync_directory) && !file_exists($sync_directory) ) {
      echo "is link true, and sync directory false";
      echo $sync_directory;
      }
    elseif ( is_link($sync_directory) && file_exists($sync_directory) ) {
      echo "is link true and sync directory exists";
      echo $sync_directory;
    }
    elseif ( !is_link($sync_directory) && file_exists($sync_directory) ) {
      echo "is link false and sync directory exists";
      echo $sync_directory;
    }
    else {
      echo "none of the above\n";
      echo "islink \n";
      echo is_link($sync_directory);
      echo "realpath \n";
      echo realpath($sync_directory);
    }

i get

is link false and sync directory exists
sites/default/files/sync
[notice] Starting Drupal installation. This takes a while.
is link false and sync directory exists
sites/default/files/sync
[notice] Performed install task: install_select_language

on drupal-core-developmen-project template
results in

none of the above
islink 
realpath 
/var/www/html/web [notice] Starting Drupal installation. This takes a while.
none of the above
islink 
realpath 
/var/www/html/web [notice] Performed install task: install_select_language

just wanted to leave that here as additional info

[rpkoller]

if i set a breakpoint in the settingseditor.php on the main branch i never get into that file during the install while with the drupal-core-development-project template i do. meaning with the latter the constraints are met to trigger the writing of settings to the settings.php

[rpkoller]

another detail i'Ve noticed. when looking into the files folder on the project built with the drupal-core-development-project there seems to be that always new sync folders with the hash appended to the name are being added

[rpkoller]

and based on randys suggestion i tested locally with mutagen disabled (the issue still is in full effect) and same for testing the same on coder.ddev.com with linux under the hood. same case the issue happens there as well.

[rfay]

This is a fundamental problem with this project and Drupal.

• Drupal's install.php and other tools assume that the docroot is ".." from the core/install.php. In this project, core is symlinked, so as soon as that happens, drupal assumes that the docroot is repos/drupal instead of the expected web copy. See https://git.drupalcode.org/project/drupal/-/blob/main/core/install.php?ref_type=heads#L11
• The same problem occurs in guessApplicationRoot, https://git.drupalcode.org/project/drupal/-/blob/main/core/lib/Drupal/Core/DrupalKernel.php?ref_type=heads#L345

This could be fixed in Drupal, but I doubt it's worth the headache.

Probably the problem is that install.php needs to be patched, as other things get patched. But DrupalKernel.php might need patching as well

[joachim-n]

This could be fixed in Drupal, but I doubt it's worth the headache.

There's an issue to fix this in Drupal, with a MR I try to keep up to date. Link in this project's README.