Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.See http://groups.drupal.org/node/24746
I can reproduce this on sites created fresh out of Aegir. It does not occur on sites I have migrated into Aegir (as the database already exists)
It looks like sites created in Aegir are not setting a value for install_task variable and so are getting around the check in install.php, function install_verify_drupal:
/**
* Verify if Drupal is installed.
*/
function install_verify_drupal() {
// Read the variable manually using the @ so we don't trigger an error if it fails.
$result = @db_query("SELECT value FROM {variable} WHERE name = '%s'", 'install_task');
if ($result) {
return unserialize(db_result($result));
}
}
// Check if Drupal is installed.
$task = install_verify_drupal();
if ($task == 'done') {
install_already_done_error();
}
But I'm no expert.. not sure.
Note that after the first few steps of the install are done, after choosing a Language, the install does fail due to the database already being populated.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 533974.patch | 595 bytes | mig5 |
Comments
Comment #1
Macronomicus commenteduh ohh ... i can reproduce this even when logged out and with perms on install.php set to 0700
Comment #2
Macronomicus commentedWhen viewing my online server though .. I get a drupal already installed page (even when logged out)
I figured install.php was important for site creation but its not ... changing the name to install.php~ worked.
Are these install files supposed to be deleted afterwords?
Comment #3
redpuma commentedConfirm this too is the case for my sites created with Aegir.
Comment #4
Anonymous (not verified) commented(was meant to be a reply to macrocosm #2)
No, and it's nothing to do with permissions, it's because a check in install.php is done to find a value in the database, a value which a regular Drupal site inserts, but Aegir's provisioning is not. Because a match is not found, Drupal doesn't have a reason to think the site's already been installed.
(at least that's my theory on what is going on).
Note that even if you try to proceed with the installation, it'll fail after the 'Choose Language' step. So (in my opinion) it's not as critical as it looks for the moment, because (in my tests, anyway) it fails and doesn't overwrite what's already in the database.
P.S sorry guys, I guess this bug report probably belongs in the Provision queue, it seems to be the one calling things like system.install which is meant to do the job of inserting that value into the db, but doesn't appear to in the provisioning case nonetheless.
Comment #5
Anonymous (not verified) commentedAlso quick note: this occurs for sites provisioned on Drupal 6 platform but not Drupal 5, I think because Drupal 5 doesn't make the same checks for that value in install.php the way Drupal 6 does.
Comment #6
adrian commentedmarking critical
i think we can just modify the sites.php template
Comment #7
Anonymous (not verified) commentedI added a variable_set('install_task', 'done') to the end of install_main() in provision/platform/drupal/install_6.inc and as expected, it fixed the issue for me. Patch attached
I don't know if something similar would be required for Drupal 7 as I'm unfamiliar with it (i.e is it different again, given Drupal 5 didn't perform this check).
Comment #8
anarcat commentedTaking a look at this. I'm of the opinion this is actually a minor issue although annoying, I don't think existing sites should be fixed.
Comment #9
anarcat commentedCommitted your patch, even though it wasn't clean (you should diff from the top of the module tree, not in the directory). Thanks!