drush update causes modules' external dependencies to be removed

Perhaps we could skip backup if backup-dir == 'NONE'

Subscribing. This has hit me with ApacheSolr upgrades and its required third-party PHP client.

Same with fckeditor. However when this happened I also found there was a new version of the external program. Perhaps updating these external programs could be within the scope of Drush and / or plain Drupal?

@AFowle: I recommend switching from fckeditor to ckeditor. See this. The issue of upgrades remains, though, and I agree that it would be spiff if drush handled it.

Moshe does upgrades via a post-enable hook in the d7 version of devel. This works fairly well for downloads, but upgrades are harder. pm-updatecode can't very well include the php files just upgraded; it would cause conflicts in php function names. This could be fixed via backend-invoke, but then things get a bit more complicated & ergo harder for module developers to support.

I have an idea: put externality[] elements in a modules .info file that contain the name of the external component and the url to get it from. During an upgrade, drush could notice when the url to the externality changes (e.g. due to a new version being required); this would be pretty easy if pm-updatecode gathered the externality info before and after the update. No change == preserve the externality (if using the 'backup' versioncontrol engine), new url == download the externality to its new location.

This technique would also mean that jquery_update would get its external dependency before it was enabled, which would really help out features that depended on that module.

My ideal solution to this would be for Drush to generate a patch file and apply it instead of replacing the module folder wholesale.

Before I discovered Drush (and after I accidentally deleted external dependencies once too often), I wrote a module update tool that creates multi-dimensional arrays representative of the current and updated module directory structures then recursively compares the two and reports any files or directories in the current version of the module that aren't in the updated version and allows me to add those file and directory paths to a '$protected' array for non-deletion during update.

It seems like something like this could work for the Drush update code. (I'd offer my code but it's not very Drush-like at the moment.)

James

subscribing

I don't know if there's a reason for a module to not use sites/all/libraries or the corresponding site-based folder. I think efforts toward this are more useful.

I agree with the sentiments in both #9 and #10. wysiwyg uses sites/all/libraries, which is much more convenient than modules that store dependent files in the modules folder. However, I'd say that it isn't possible to fix all non-compliant modules, and it would be helpful if drush supported updates to files with external dependencies.

My idea in #5 is no good, though, as it requires modifying the module to make it compliant, and as jonhattan said, it's be better to just fix the module. So, some other technique would be better. This is on my to-do list, but it's just a nice-to-have for me, as I don't think I'm using any modules of this type at the moment. Patches welcome. ;)

I think this is a duplicate of #436978: Improve detection and handling of local contribs with local changes before an update - maintaining external dependencies is basically the same problem as maintaining local changes. Feel free to reopen if I have missed something!

I agree that the most elegant fix is to patch these modules to use /libraries, rather than storing things in the module folder.

Agreed; I put a cross-link back to here.