This is due to #346494: DB drivers need to be able to change the configure database form during install, which changed the structure of the database configuration form. Simple fix attached - this seems to work for me.

Comments

moshe weitzman’s picture

Status: Needs review » Fixed

Committed. Thanks.

David_Rothstein’s picture

@das-peter found that this doesn't work in all cases. If you have more than one database driver on your system and try to install with the non-MySQL one (in particular with SQLite), the wrong form validation runs and the Drush install fails.

This seems to be a core issue, though: #992928: Command line (Drush) install fails on SQLite ($form_state['input'] is not always populated for programmatic form submissions)

greg.1.anderson’s picture

I just encountered the same situation with drush site-install for d6: the install fails if you have both mysql and postgres, because the install script cannot handle the database selection form (the one that is skipped when there is only one driver).

Is this really a core issue, or a drush issue? I'm not sure, as the d6 and d7 site-install functions are unrelated.

Garrett Albright’s picture

Issue tags: +sqlite

I looked into this tonight. I'm pretty sure it's a core issue, since Drush seems to be handling its part of the process just fine - it's only after it passes stuff off into core's functions that they start to go all sideways. See the issue David_Rothstein linked to.

Garrett Albright’s picture

Status: Fixed » Needs work

Reopening because I've determined that this is in fact a Drush bug, in drush/commands/core/drupal/site_install_7.inc - $settings isn't being set to something Drupal expects. A social event is preventing me from working on this further at the moment (darned real life!), but I'll see if I can hack out a fix later tonight, if I'm up for it.

moshe weitzman’s picture

I can reproduce this on my windows install but not my OSX. That probably an artifact of how they are configured rather than OS making a difference.

The error is being set at if (isset($elements['#needs_validation']) && $elements['#required']) { in _form_validate() and it is the name of the pgsql database that is being checked. Note that i am installing to mysql so naturally pgsql values are empty. Is this validation not supposed run? If not, then maybe #needs_validate should be FALSE for this pgsql-database element. #needs_validation is TRUE.

moshe weitzman’s picture

Status: Needs work » Fixed

Was a drush issue. Namely, I was not setting 'op' => dt('Save and continue'), on each of the forms so the button that carries the #limit_validation_errors was not in form_state[#input] (David noted this symptom in #2).

I don't know why this started failing now though.

David_Rothstein’s picture

Status: Fixed » Needs review
StatusFileSize
new1.13 KB

Turns out there is still both a Drush bug and a core bug. More details are at #992928: Command line (Drush) install fails on SQLite ($form_state['input'] is not always populated for programmatic form submissions).

Here is the Drush fix. The important part is the first line - removing the 'op' stuff isn't strictly necessary (and whether it should be removed depends also on the exact final version that gets committed as part of the core patch, but I think it will be OK to remove in the end).

The main problem here in Drush is just that with the originally committed patch in this issue we were never actually selecting the driver itself anymore. Oops :( I am not sure how I missed that before.

moshe weitzman’s picture

Committed. Decided eventually to leave the op lines in place. Will remove if core no longer requires them.

moshe weitzman’s picture

Status: Needs review » Fixed

Removed the $op since that patch landed in core.

David_Rothstein’s picture

Pretty sure the $op still needs to be there actually. Since that part of the patch was removed before it was committed to core...

moshe weitzman’s picture

Current code is working for me.

webchick’s picture

Status: Fixed » Active

Hm. Not working here on a new installation (freshly cvs up -dPCA from moments ago).

$ drush dl drupal-7.x-dev
Project drupal (7.x-dev) downloaded to /Users/webchick/Sites/drupal-7.x-dev.                                [success]
Project drupal contains:                                                                                    [success]
 - 3 profiles: testing, standard, minimal
 - 4 themes: stark, seven, garland, bartik
 - 47 modules: drupal_system_listing_incompatible_test, drupal_system_listing_compatible_test, user, update,
trigger, translation, tracker, toolbar, taxonomy, system, syslog, statistics, simpletest, shortcut, search,
rdf, profile, poll, php, path, overlay, openid, node, menu, locale, image, help, forum, filter, file,
field_ui, text, options, number, list, field_sql_storage, field, dblog, dashboard, contextual, contact,
comment, color, book, blog, block, aggregator
$ cd drupal-7.x-dev
$ drush si --db-url=mysql://root:root@localhost/core                             
                  
You are about to create a sites/default/files directory and create a sites/default/settings.php file and DROP your 'core' database and then CREATE a new one. Do you want to continue? (y/n):  y
Starting Drupal installation. This takes a few seconds ...                                                  [ok]
WD php: Exception: Database name field is required.                                                         [error]
Database username field is required. in install_run_task() (line 418 of
/Users/webchick/Sites/drupal-7.x-dev/includes/install.core.inc).
WD php: Warning: Cannot modify header information - headers already sent by (output started at              [warning]
/Users/webchick/drush/includes/drush.inc:692) in drupal_send_headers() (line 1040 of
/Users/webchick/Sites/drupal-7.x-dev/includes/bootstrap.inc).
Exception: Database name field is required.
Database username field is required. in install_run_task() (line 418 of /Users/webchick/Sites/drupal-7.x-dev/includes/install.core.inc).
Drush command terminated abnormally due to an unrecoverable error.                                          [error]

However, "drush si" from an existing installation works fine.

moshe weitzman’s picture

Status: Active » Fixed

OK, rolled back my removal. David warned me in #11.

About to release Drush RC5.

webchick’s picture

Working now. :) Thanks!

David_Rothstein’s picture

Strange that it stopped working with mysql too... that I wouldn't have expected. It always worked with mysql before because that is compatible with the default validation.

I tried Drush RC5 with sqlite also and am able to get that working as well. Thanks!

Status: Fixed » Closed (fixed)
Issue tags: -sqlite

Automatically closed -- issue fixed for 2 weeks with no activity.