For simplytest.me, I have been trying to implement a feature to bypass the installation and allow people to configure an installation at their discretion. However, the system still sponsors the Drupal database for each provisioned site. It became a significant usability issue when the installer asked for database credentials.

I attempted to solve this by populating a settings file with the database credentials. This populated the database credentials in the install form. Except, when clicking "submit", it stated that "Drupal was already installed." This was with an empty database. I tried it with no database and passing a user that had the ability to create a database. Same results.

Is there a way to send the installer database credentials? Are there differences between Drupal 7 and 8? Help wanted.

I'm aware that any potential patches created from this issue will likely only be applied to specific 8.x branches. This means I'll still need to find some work arounds for older versions, as Simply Test allows users to select any release.

Thanks in advance for any assistance.

Comments

nerdstein created an issue. See original summary.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nerdstein’s picture

nerdstein
he/him
Primary language English
Location United States
CreditAttribution: nerdstein as a volunteer and at Hook 42 commented
Title: Clarity on passing database credentials to install.php » Missing hash salt throws AlreadyInstalled exception during manual installation when settings.php already exists
Category: Support request » Bug report

I was finally able to dig into this a bit deeper. And, I'm updating the title accordingly.

For some background, I wanted to prepopulate database credentials during installation. Steps I tried:

1. Copy default.settings.php to settings.php and add the $databases array

2. Add a blank settings.php and add the $databases array

A few other notes during debugging:

1. Permissions on all of sites/default were open

2. The database itself was completely empty and new

Both resulted in an AlreadyInstalled exception that suggested there was already a site installed. This wasn't true.

I started digging into working solutions, like DDEV, that populate settings pre-install and have a working manual installation. The setting that was causing this was the$settings['hash_salt'] in D8 and $drupal_hash_salt in D7. This suggests it's a required setting. Is this intentional? A manual installation works without any prepopulated settings, which includes the hash_salt.

TL;DR - if you pass database credentials, you need to also supply a hash salt.

If this wasn't intentional, would it be possible to generate a hash if only database credentials are passed? I'd be happy to work on this if it is indeed a bug.

If it's not, this may be an opportunity to improve the documentation around pre-populating settings before installation.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

JamesOakley’s picture

JamesOakley
he/him/his
Primary language English
Location Kent, UK
CreditAttribution: JamesOakley as a volunteer commented
Related issues: +#3195562: Installer does not pick up password value from settings.php when hash_salt is not pre-populated

I've just hit this same problem, and I can shed some further light on it.

1. I see this issue was first created when Drupal 8.8 was the latest major release. I have successfully installed 8.8, with database credentials pre-supplied in settings.php, so the problem does not always happen. I'm now installing a new site on 9.1.3, and using the same Composer.json file (apart from updating a few things to pick up Drupal 9 versions), and I've hit the problem. I initially thought it may be a bug that's crept in between 8.8 and 9.1, but it seems not given when you first reported this.

2. The reason you get the "site already installed" message seems to be because the installer succeeds in creating exactly 10 tables (the same 10 every time), before something makes the installer pause to check again that the database isn't already populated. Quite why the eleventh table fails for this reason when, and only when, hash_salt has not been saved to the settings file is a mystery. But it's specific enough that it may help debug this.

The installed tables are as follows, with numbers of rows in brackets:

  • batch (1)
  • config (44)
  • key_value (61)
  • queue (34)
  • sequences (1)
  • sessions (1)
  • users (2)
  • users_data (0)
  • users_field_data (2)
  • user__roles (0)

3. When installing with the database credentials pre-filled in settings.php, I've noticed that, not only does the hash_salt not get saved to the file, but I'm still being prompted to enter database credentials. Specifically, the "Database Configuration" setup screen gets shown, with the username and database name populated, but the password field is empty (even though the password value is included in settings.php). I'll open a separate issue about that; it seems related (this only happens if hash_salt is not also pre-populated in settings.php), but could be a distinct issue. #3195562: Installer does not pick up password value from settings.php when hash_salt is not pre-populated

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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: 10.1.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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.