Problem/Motivation

It's impossible to use dr install on ddev without manipulating settings.php first.

$ dr install standard
Drupal is already installed. If you want to reinstall, remove sites/default/files and sites/default/settings.php.

This is not ddev specific. If you already have a configured database you run in to the same problem. In fact, you can start an install and cancel it mid-way through, then you're stuck.

Steps to reproduce

Run dr install standard twice

Proposed resolution

Prompt the user to confirm if they want to proceed, or require --force or -f or similar.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3594320

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mstrelan created an issue. See original summary.

mradcliffe’s picture

mradcliffe
he/him
Primary language English
commented
Parent issue: #3453474: CLI entry point in Drupal Core » #3582246: [meta] CLI in Core community initiative
Related issues: +#3453474: CLI entry point in Drupal Core, +#3594342: Update install command to allow installing using any database driver

Updated parent issue to the meta, and I added a related link to an issue I created to improve install to let it install on any database driver. These may be related/duplicated, sorry.

quietone’s picture

quietone commented

@mstrelan, thanks for making this issue!

mstrelan’s picture

mstrelan commented

I've submitted this as a feature request, however if this is meant to have parity with drush then this could be considered a bug.

balsama made their first commit to this issue’s fork.

balsama opened merge request !16259

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented
Status: Active » Needs review
mradcliffe’s picture

mradcliffe
he/him
Primary language English
commented

The one issue here is that install currently only installs via sqlite so the following scenario will have confusing results:

1. Setup a Drupal environment with settings.php created with a real database connection, not SQLite.
2. Run dr install standard.

This will install with the existing database connection and not SQLite, which would be currently misleading because help is saying this isn't meant for production.

I think I am okay with this as long as setHelp is changed to clarify current usage.

This would be a quick win for local ddev environments for drupal 12 developers, and hosting providers with automated configuration, but not self-hosters.

What do you think?

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented

Didn't realize the help text was so explicit. I just pushed a commit with this change to the help text:

If a connection to a database is defined, it will be used. If no connection is defined a SQLite database will be created and used which is not meant for production and might be too simple for custom development.

Happy to tweak that again if anyone has suggestions.

xmacinfo’s picture

xmacinfo
he/him
Primary language French
Location Canada
commented

Would it be better to use a drop (-d) flag to drop existing database?

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

`drop` is a destructive operation, and may require extra privs (and the user may not have privs to recreate). The correct behavior of `ddev sql-drop` over the years is to delete all tables. That's a great approach. (Dropping the `db` database in DDEV is a terrible thing to do.

xmacinfo’s picture

xmacinfo
he/him
Primary language French
Location Canada
commented

@ray I agree 100% with you. By drop I meant delete all tables.

But we could still use something like dr install -d to (d)elete all tables before installation.

xmacinfo’s picture

xmacinfo
he/him
Primary language French
Location Canada
commented

Scenario - Database has tables in it

dr install — issues an error
dr install -d — deletes all tables and perform the installation

rfay’s picture

rfay
he,him
Primary language English
Location Palisade, CO, USA
commented

Drush's `drush si -y` is good enough for me :) Has been for 20 years or something.

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented

I'd argue to keep the scope here tight. As it stands, users who set up a DB connection before installing Drupal (as is the case on managed hosts and ddev) can't use dr to install Drupal. The current MR allows them to do just that without changing the default behavior for environments that don't have their DB connection defined.

Suggest opening a related issue to add a `db:drop` command that can be used in conjunction with this command for repeated installs.

balsama’s picture

balsama
he/him
Primary language English
Location boston
commented

I've made a few updates to MR:

  • Changed the help text to @mradcliff's suggestion
  • Explicitly add a request host for CLI installs so that URLs to files get created properly (previously failed when installing from certain recipes)
  • Only require the pdo_sqlite extension if sqlite is actually going to be used.
  • Changed the "already installed" warning message to instruct the user to drop the defined database (rather than delete the filed directory)