Closed (fixed)
Project:
Drush
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
14 Jun 2010 at 22:16 UTC
Updated:
3 Jan 2014 at 01:42 UTC
Jump to comment: Most recent, Most recent file
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?
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | updatecode_profiles_mkII.patch | 594 bytes | acrollet |
| #3 | updatecode_profiles.patch | 609 bytes | acrollet |
| drush_updatecode_profiles.patch | 945 bytes | acrollet |
Comments
Comment #1
greg.1.anderson commentedI 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.
Comment #2
greg.1.anderson commentedComment #3
acrollet commentedhere'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...
Comment #4
moshe weitzman commentedCan'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.
Comment #5
greg.1.anderson commentedHm, 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.
Comment #6
acrollet commentedattaching a patch using greg's idea - tested working fine. (custom profiles are preserved, default is copied over)
Comment #7
seanrOooh, I'll be very happy when this gets in since it currently wipes out the install profile we're using for multisite installs.
Comment #8
greg.1.anderson commentedI 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).
Comment #9
moshe weitzman commentedi didn't test this but code looks sound. greg or i will commit soon.
Comment #10
greg.1.anderson commentedCommitted. Could go in 3.x too.
Comment #11
moshe weitzman commentedWill roll a release soon. Committing critical backports.