We need to be able to deal better with damaged sites. Here, there was a permissions screwup on drushrc.php, and then verify actually destroyed the information in settings.php and couldn't recreate the drushrc.php properly. So the situation was that the authentication information was lost, both in drushrc and settings.php. Site unrecoverable. I should be able to disable then delete it from the system.
First blocker is this in platform/disable.provision.inc, drush_provision_drupal_provision_disable_validate() does a site bootstrap which fails and pops up an error. First bad idea.
Second blocker is the backup validation which does exactly the same thing.
I propose to remove the validation from disable (since it's done in backup and is not required by validate per se) and make the bootstrap fail in backup only if force is off.
Patch attached.
Comment | File | Size | Author |
---|---|---|---|
#1 | strong_disable.patch | 1.56 KB | anarcat |
strong_disable.patch | 4.82 KB | anarcat |
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedGetting rusty with patches, reroll without extra changes.
Comment #2
anarcat CreditAttribution: anarcat commentedCommitted to CVS.
Comment #4
anarcat CreditAttribution: anarcat commentedThis is still relevant. If a site disappeared from the backend, it will not be possible to disable/delete it from the frontend. The problem is in the backup bootstrap:\
This is probably related to:
Comment #5
anarcat CreditAttribution: anarcat commentedSo I have a rather crude hack for this, not sure it's really nice to do this, would like to get feedback from adrian before committing:
http://git.koumbit.net/?p=drupal/modules/provision/.git;a=commitdiff;h=3...
Comment #6
adrian CreditAttribution: adrian commentedthis looks sane , feel free to commit.
Comment #7
anarcat CreditAttribution: anarcat commentedPushed to CVS.