Updated module installed in the wrong folder [#1016892]

When updating, the new version seems to be installed in a subfolder of the old version itself.
It's only happening with the Date module, but perhaps due to the fact that this particular module has a folder called "date" in its own "date" folder.

Comment	File	Size	Author
#2	1016892-2-hacky-solution-but-needs-work.patch	1.34 KB	bfroehle
#2

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

bfroehle CreditAttribution: bfroehle commented 7 January 2011 at 00:38

I'll confirm that this is indeed an issue in the 7.x-dev.

Steps to reproduce:

Download and install Drupal 7
Install Date 7.x-1.x-dev in sites/all/modules
In admin/modules/update, choose to upgrade the Date module.

Expected Result:
Date module is updated correctly in sites/all/modules.

Actual Result:
The updated Date module is installed in sites/all/modules/date. (That is, date.module is located in sites/all/modules/date/date/date)

Comment #2

bfroehle CreditAttribution: bfroehle commented 7 January 2011 at 01:41

Status:

Active

» Needs review

File	Size
1016892-2-hacky-solution-but-needs-work.patch	1.34 KB

The fundamental issue here is ModuleUpdater::getInstallDirectory() just returns the parent directory of the directory which contains the specified module. The 'date' module is presumably located in sites/all/module/date/date/date.module and the parent directory is then sites/all/modules/date.

Attached is a hacky patch, which works for me for updating the Date module (which has this 'flaw') and the Devel module (which is a more normal module).

This is still at 'needs work,' since it is lacking in comments, changes the behavior of Updater::getProjectName(), and doesn't include a similar for for 'themes'. (I suspect Zen, for example, would be a theme also affected by this bug).

A better solution would be to update drupal_get_path to allow 'project' as a type, but I haven't looked into the feasibility of that.