The bug is pretty much as described - the $profile global isn't set when update_main_prepare() is called, and so all themes under the /profiles directory aren't re-inserted into the system table when system_theme_data() is called. As you can imagine, this leads to general unhappiness when all theming disappears! I've attached a patch that fixes the problem, but I fully recognize that it's probably similar to using a 30 ought 6 to kill a fly... Happy to defer to any drush maven, or try to improve the patch with tutelage.

thanks very much!

CommentFileSizeAuthor
#4 update_6_inc_modified.patch342 bytesacrollet
#4 drush_updb_bug.build_.txt215 bytesacrollet
update_6.inc_.patch400 bytesacrollet

Comments

acrollet’s picture

acrollet commented

Quick note for any others that are experiencing this problem - We've only seen it with drupal-6.16.

acrollet’s picture

acrollet commented

another note - this is probably related to #602182: updatedb should clear cache, which seems to have happened between drush 2 and drush 3 - we started having this problem around the time we upgraded to drush 3. Restoring the cache clear operation would probably fix the symptoms, though not the underlying issue I'm reporting here.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Needs work

update_main_prepare() has a global $profile and a full bootstrap. There may be a bug here, but I think you are just duplicating code so far.

acrollet’s picture

acrollet commented
StatusFileSize
new drush_updb_bug.build_.txt215 bytes
new update_6_inc_modified.patch342 bytes

Ok,

thanks for the pointer - for what it's worth, #602182: updatedb should clear cache does not fix this issue.

I have found and verified that the call to drush_get_projects() (which calls drush_get_themes()) in update_main_prepare() is what is removing themes under /profiles from the system table. There is indeed a global $profile and full bootstrap with update_main_prepare(), before the call to drush_get_projects(), but the only thing I've found to fix the issue so far is to run the full bootstrap before calling update_main_prepare(). (It turns out that the global $profile is not necessary, removing that from the attached patch)

I can verify that this is a reproducible bug, to reproduce, simply build the attached makefile and run 'drush updb' on the new site.

webkenny’s picture

webkenny commented

I am going to dig into this today too, Moshe. Curious if it blows away anything else and if not, perhaps we can avoid the full bootstrap and go with restoring or refactoring only what it kills. We're seeing this a couple of times with customers.

Kenny @ Acquia

acrollet’s picture

acrollet commented

FYI - just verified that this bug still occurs with drush-HEAD + drupal-6.17.

webkenny’s picture

webkenny commented
Assigned: Unassigned » webkenny

I'm currently looking into the particular function in the bootstrap which restores the themes. This might be a better option than bootstrapping twice. I'll come back here when I have something.

tnightingale’s picture

tnightingale commented

Here is a core issue with more discussion related to this one: #545452: Store install profile in the generated settings.php file

We are also experiencing this. The workaround recommended in Open Atrium here, is to set a variable "install_profile" so that drupal is aware of the profile location at an earlier stage in the bootstrap.

This seems to solve this particular case where drush updb causes the theme to get dropped. However we are still encountering the issues with update.module identical to what is detailed here: http://drupal.org/node/578144#comment-2982044

I am currently looking into the update status issue, if anyone has any updates to the information documented here please post :)

msonnabaum’s picture

msonnabaum commented

I just ran into this with Drupal Commons now that we moved everything to the profile.

Using this workaround in settings.php seems to work for now:

$conf['install_profile'] = 'drupal_commons';
moshe weitzman’s picture

moshe weitzman commented
Component: Code » PM (dl, en, up ...)
Assigned: webkenny » Unassigned
Priority: Critical » Normal

we have a well known workaround that seems to have reduced the research desire here. downgrading. i'd still love some root cause analysis here.

greg.1.anderson’s picture

greg.1.anderson commented
Version: » 8.x-6.x-dev
Status: Needs work » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.