Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.When you have a custom module folder name (e.g. "cck_5" instead of "cck"), drush breaks your drupal installation by moving the whole "sites" foilder from your drupal root directory to "backup".
Steps to reproduce:
1) Install drush 5.x-1.4 module and enable Drush, Drush Package Manger and wget support
2) Download and install an old version of a module, e.g. http://ftp.drupal.org/files/projects/cck-5.x-1.9.tar.gz in "sites/all/modules"
3) Extract the package and move the resulting folder to a custom name (e.g. "cck_5")
4) Enable the module (e.g. CCK) on your site
5) run "drush pm refresh" and "drush pm update " (e.g. "drush pm update cck")
6) Have a look at your drupal root directory: the "sites" folder is gone, the new cck module folder is here
7) Try to visit you drupal site in a browser ==> it is broken.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | drush_cck_screenshot.jpg | 108.26 KB | tylerwalts |
| #2 | drush_368992.patch | 1.84 KB | klausi |
Comments
Comment #1
klausiHm sorry, there seems to be an older bug report, too: #269410: Drush backup removes sites directory
Comment #2
klausiI looked into it and did a patch for the drush_pm_get_project_path() function (see attachement).
This does not solve the problem completely, but it stops sites from breaking for now. An update is possible with this patch, but the downloaded module gets stored under its default name. This seems to be by design, because the handler API (for wget, cvs etc.) does not take a custom module directory name into account.
Comment #3
moshe weitzman commentedall this code changed.
Comment #4
tylerwalts commentedI just experienced a similar case with my 6.x install. The cck module was not installed in the proper /sites/all/modules/cck/ location, so when the code searches for the module name within the module's path and doesn't find it, by default it moves the base folder of the path (/sites/) to the backup location, instead of just the module path. Maybe default action should check for this case?
I was testing a 5.x to 6.x bash/drush upgrade script that tried to move the new /cck/ folder into the /sites/all/modules folder, only it was fresh from extracting core archive and didn't exist, so what should have been /sites/all/modules/cck/* turned into /sites/all/modules/* (so all the cck files were in the root modules folder). I had recently made a change in the way that cck is upgraded, acording to the documentation it has to go first. So I had moved it up too far and tried to install it before the new /sites/all/modules directory exist. Fixed it by making sure the /sites/all/modules directory was created first in the script. (Off topic, but I am still confused on why drupal core doesn't ship with /sites/all/modules and /sites/all/themes directories already existing, since it is the best practice drupal way to use those location.)
Comment #5
boabjohn commentedThis thread is marked for 5x, but I'm using drush_all-versions_2.1 on a D6.15 installation.
Drush seems to have hit a bump on my FCKEditor install, and shifted the whole sites directory to the /backup/.. location in same manner as described above.
This freaked me out (to say the least) and fortunately I had access to the server so I could locate the shifted site assets.
If it's any help I can send a copy of the drush log and a directory tree for FCKEditor.
But I'd say it looks like drush still having trouble with any sort of custom module naming.