redis/scripts/setup-drupal-settings.sh creates settings.php incorrectly if it is not alreay present

[drakythe]

Ran into an issue today setting up a ddev environment for drupal with redis. If the ddev get ddev/ddev-redis command is issued before the ddev start command the setup-drupal-settings.sh file ends up creating a settings.php file with only its configuration in there. The ddev start command then appends the standard settings.ddev.php stuff in there as well. However, the drupal site will fail to install because the settings.php file created by the redis script was done so without copying the default.settings.php or even adding in the php open tag, so drupal fails to install as it cannot find a valid database connection string since the settings.php without the opening php tags won't properly load in settings.ddev php.

Proposed fix would be to adjust the script to check for the existence of settings.php and if it does not exist then create it by copying default.settings.php before appending the redis settings to the file.

[rfay]

So you created a project with no code in it, then did a ddev get ddev/ddev-redis, then did the first-ever ddev start?

Please give a step-by-step way to create this problem with a new project.

I know that a PR would be very welcome. I'm not 100% sure that one could count on the default.settings.php if the settings.php is not there.

[drakythe]

@rfay Sure, my apologies!

Our setup is probably a little bit of an edge case given how we use ddev.

1. We clone down our development platform into a folder, included in this repository is a composer.json, composer.lock, and .ddev/config.yml so all of our developers are on a consistent environment.
2. we run composer install --ignore-platform-reqs so that the host system doesn't need all the extra php modules and such, just composer. This increases install speed and gets us the benefit of the composer cache across multiple ddev projects.
3. At this point we have a drupal site and a basic .ddev/config.yml file. Since we haven't yet run a ddev start and it would just be extra time to start it, add redis, and restart the system, we run ddev get ddev/ddev-redis && ddev get ddev/ddev-redis-commander command
4. ddev start
5. ddev drush si profile_name -y

Step 5 returns an error that it couldn't connect to the database. Step 3 is what actually broke the system though by created a non-php settings.php file.

I will be happy to submit a PR once I remember how to do so in github. Been too long!

[drakythe]

Okay, this appears to be more edge case than I thought. I just tried to recreate this scenario using the ddev cms quickstart instructions as a base. Only I ran the composer composer project create first using the --ignore-platform-reqs flag. However, the settings.php file was created somewhere in the process even before I did a site install (or ddev start).

I will investigate further.

[rfay]

We encourage people not to use php or composer on the host at all because of different behaviors based on php and composer version. So we'd encourage you to use ddev composer create - With that setup there's no need to do anything with ignoring reqs or anything else.

And... I think with that setup you'd already have a settings.php always.

Could you try it again using the recommended flow?

[stasadev]

Over the past year, ddev composer create was updated to ddev composer create-project, which is now nearly identical to composer create-project and is the recommended command to use.

Closing this issue.