Closed (works as designed)
Project:
Availability Calendars
Version:
7.x-3.2
Component:
Miscellaneous
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
25 Apr 2012 at 18:11 UTC
Updated:
29 Apr 2012 at 06:50 UTC
Drush downloads this module to /modules/availability_calendars
This can be fixed by creating a new project in d.o. with the correct name. I do not know of any other methods.
Are there any plans of bringing back the old name? That complies with the modules name?
Comments
Comment #1
fietserwinA request for renaming the project on d.o. has been refused (#1257442: [D7] Availability Calendar). And renaming all files/functions in the current code to the plural form will collide with the 7.x-2.x version that may be needed for upgrading your data. So I guess that it is not that easy to solve.
Perhaps that this is a valid reason to reopen the mentioned issue?
Comment #2
bserem commentedMaybe, but this I cannot really say.
Perhaps tim.plunket should be informed and help reach a decision.
Comment #3
fietserwinDid you try to discover why Drush does so? In other words: isn't this a bug in Drush? Because it is allowed to install modules in a directory with a different name, think of sub-modules. If not, I will reopen the mentioned issue.
Comment #4
bserem commentedI didn't new Drush can install module under a different directory name. I new it installed all modules under a directory named after the project name.
I'll look into it. I simple "drush dl availability_calendars" did install the latest version under a wrong folder name though.
It might have to do with the way drupal.org packages the tar.gz archive. I believe drush gets this archive and extract its.
Comment #5
fietserwinHmmm, do you mean sites/all/modules/availability_calendars? (you mentioned /modules/availability_calendars, suggesting it was placed alongside the core modules, but on testing I saw it just installs in sites/all/modules). If so, this is expected behavior. The installer with UI does the same, as will be the case when you manually download and extract the tar.gz. This is because the project is named after the plural form (thus with an s), but the module is singular (thus without an s).
Though this might not be common or best practice, it is perfectly allowed within Drupal. The Drupal updater will look at the project setting in the .info files of an module to find the (project page and) releases on drupal.org.
So, closing as working as designed. If you did mean the Drupal core modules directory please reopen.
Comment #6
bserem commentedNo, I meant /sites/all/modules, you are right. Sorry for the fuzz.
So, is it ok to leave the module in "/sites/all/modules/availability_calendars". It won't produce any problems now that the module is named without the "s" ?
Comment #7
fietserwinNot at all, it is the expected place for all types of installation (Drush, UI, manual) and moreover it is of course never hard coded.