Posted by acrollet on June 14, 2010 at 10:16pm
5 followers
| Project: | Drush |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | moshe weitzman |
| Status: | closed (fixed) |
| Issue tags: | installation profiles |
Issue Summary
symptoms - if you run drush up drupal on a site created with drush make + an install profile, all modules installed under /profiles/{profile-name} will disappear, and the message: "The module x is incompatible with this version of the Drupal core" appears for each module.
The patch attached fixes the issue for us.
Please see #806190: drush updb removes themes under /profiles from the system table for another example of drush not handling similar sites correctly. Perhaps a site created with drush_make and an installation profile could be added to whatever testing regimen may exist for changes to drush?
| Attachment | Size |
|---|---|
| drush_updatecode_profiles.patch | 945 bytes |
Comments
#1
I think you can skip that loop and just do this:
$project['skip_list'] = array('backup', 'sites', 'profiles', $project['path']);It shouldn't hurt anything if there aren't any profiles.
#2
#3
here's a patch for review - I guess it doesn't matter if any changes to the default profile aren't updated, since it would only run on initial install...
#4
Can't a new version of drupal core include changes to the default profile? Its a little disturbing to not update that code. Further, profiles are expected to change in drupal 7 since they can carry update functions, participate in hooks, etc. I don't think skipping profiles dir is the right fix. I'm not sure what is though. Have not looked closely at this.
#5
Hm, yes, good point. Maybe something like this would work:
// If there is a backup target, then find items
// in the backup target that do not exist at the
// drupal root. These are to be moved back.
if (array_key_exists('backup_target', $project)) {
_pm_update_move_files($project['backup_target'], $drupal_root, $project['skip_list'], FALSE);
_pm_update_move_files($project['backup_target'] . '/profiles', $drupal_root . '/profiles', array('default'), FALSE);
}
Yeah, that's a hack -- just like the rest of core update. :p I don't have time to fiddle with it right now, that's just a first hint at a direction to try. Might work, might need work, might not work...
These sorts of issues should be taken care of when updatecode is rewritten per Owen's earlier suggestions.
#6
attaching a patch using greg's idea - tested working fine. (custom profiles are preserved, default is copied over)
#7
Oooh, I'll be very happy when this gets in since it currently wipes out the install profile we're using for multisite installs.
#8
I think this is good, but I'm going to pass this to Moshe to make sure that the assumptions are correct (profiles/default is updated, with modifications thrown away, everything else in profiles is preserved).
#9
i didn't test this but code looks sound. greg or i will commit soon.
#10
Committed. Could go in 3.x too.
#11
Will roll a release soon. Committing critical backports.
#12
Automatically closed -- issue fixed for 2 weeks with no activity.