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!

Tags: DrupalCCKModulesTroubleshootingDate Module

• var switchTo5x=true;stLight.options({publisher:'dr-8d4fe24c-a8ab-ba90-8086-3791b02244be'});