Install.php does not correctly check the database settings
justinrandell - August 25, 2008 - 12:25
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | database system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
the following docs from default.settings.php don't seem to match the behaviour of the installer:
<?php
* For a single database configuration, the following is sufficient:
*
* $databases = array(
* 'driver' => 'mysql',
* 'database' => 'databasename',
* 'username' => 'username',
* 'password' => 'password',
* 'host' => 'localhost',
* );
*
* That is equivalent to:
*
* $databases['default']['default'] = array(
* 'driver' => 'mysql',
* 'database' => 'databasename',
* 'username' => 'username',
* 'password' => 'password',
* 'host' => 'localhost',
* );
?>when i use the following in settings.php for a fresh install of HEAD:
<?php
$databases = array(
'driver' => 'mysql',
'database' => 'databasename',
'username' => 'username',
'password' => 'password',
'host' => 'localhost',
);
?>i get the following error:
In your ./sites/default/settings.php file you have configured Drupal to use a server, however your PHP installation currently does not support this database type.so, is the code wrong or is the doco wrong?
#1
closing this, as it seems to be a duplicate of Select MySQL as default database driver, and fix a E_ALL warning during install.
sorry for the noise.
#2
This has nothing to do with the other one.
#3
That looks like a bug in the code, because that fallback logic is supposed to work.
I have actually been pondering removing the fancy-schmancy fallback nesting. It just burns cycles on bootstrap, and with the installer 95% of users will never write their own settings.php file anyway.
Would anyone object greatly if we just got rid of the crazy fallback stuff? I don't think it serves any purpose now that we have an automated installer.
#4
Crell: the fallback logic does not work in the installer, there is a:
<?php$database = $databases['default']['default'];
?>
in install_verify_settings()...
#5
i had a look at this, its not a trivial fix. i'm totally fine with removing/simplifying the fallback code.
EDIT: and i'd be happy to supply a doc fix patch if that's the way we decide to go.
#6
I think this problem can be fixed with a simple if/then conditional.
(I'm tempted to mark this as critical, because I wasted over an hour on it when attempting to do a "quick" 15 minute patch review and update.)
#7
Okay, that wasn't enough. I'll see if I can find where else this needs to be corrected and upload a new patch.
#8
The patch I provided (in #6) fixes the install problem, but doesn't fix the bootstrap problem that happens after Drupal is successfully installed. I've spent quite a bit of time following threads and have not yet been able to locate where it strays. I will have to come back to this later, as I need to leave for out appointments, unless the consensus is to just remove it.
#9
I finally got back to this. (I actually forgot about it.) After rereading this thread and reliving my experiences, I agree with Crell on this issue.
#10
#11
Let's get rid of it. The reason has been named before: manual editing isn't required anymore, which means this feature will be hardly ever used.
#12
+1 for removing and optimizing the hell out of the bootstrap process.
#13
Oh that is so much prettier! I just ran the Connection tests and clicked around a bit and everything runs fine. #11 is RTBC. Thanks, smk-ka!
#14
Committed to CVS HEAD. Thanks for the review, Crell.
#15
Automatically closed -- issue fixed for two weeks with no activity.