File this under "It goes without saying," but this one had me so puzzled for a time that I thought it bore repeating.
In general, a good best practice for any Drupal site is to put all third-party modules under your sites/all/modules directory; this makes for good portability when it comes time to upgrade the Drupal core, and makes it generally easier to keep track of what you've installed.
Sometimes you'll either inherit a site that has modules mingled in under the core modules directory, or groups some modules together in a subdirectory of sites/all/modules. When this is the case, make sure to check for the presence of a module in those places before you go adding it to sites/all/modules! If you have module files living in two different places, Drupal may get very confused about where to look for them, especially when it comes time to run database upgrades.
In my case, I accidentally installed a second copy of the Date module files on a development site, when in fact it was already installed and residing in another directory.
This caused all kinds of strange behavior, from having CCK fieldgroups disappear (they contained Date fields) to getting errors about missing Date module functions. Once I discovered the duplicate files and removed the extra copy of the Date module, I went into the system table and manually fixed the filename field paths. Once they were all safely pointed at the singular, authoritative location, things went back to normal.
Just one more diagnostic to add to the list of things to check next time a project starts acting up!
Agreed!
Right now I cleaning up a site with _much_ of duplicated modules. Odd behaviour is essence of this.
In our development we use such structure for modules folder:
sites/all/modules/contributed - for normail modules
sites/all/modules/custom - for our modules for this project AND modified (for some reason) 3rd party modules
this structure is very usefull for futher modules updates - we can update /custom modules with no doubt to rewrite special changes / fixes.
I had the exact same problem
I had the exact same problem but for whatever reason I couldnt get it straight so I eventually just got frustrated and erased the whole site and started over. I love Drupal's capabilities but boy can it be frustrating!
Good clarification
Thanks, Boris.
In my case I had
sites/all/modules/essentials/date
(essentials is an internal convention; it's a directory containing all of those modules one is constantly installing on new sites, included via Subversion externals)
and
sites/all/modules/date.
Drupal got very confused, and was looking for half of the files under sites/all/modules/date and the other half under sites/all/modules/essentials/date.
Should work
FYI -- sites/all/modules should really be used if it truly is going to be used on ALL sites on that install. Install profile modules are at profiles/profilename/modules
Drupal supports "multiple" modules. It's how, for example, you could "hack" the user.module and have a local, modified copy in sites/example.com/modules/user.module.
It sounds like you had something else going on. You do need to make sure to visit the modules page, and yes, be aware of which version of the module a particular site is running.
This is actually a great way to try an alpha version on the same codebase.
Post new comment