Drupal的模块目录结构非常灵活，以至于有时候会出现同样一个模块，在多个目录出现的情况。当然，这种情况很少，更多的是不一致性。

开发者之间，使用者之间，开发者与使用者之间通常都有不同的使用习惯，导致混乱发生。同时，网站代码的是否版本化，模块目录结构也跟着不同。

很长一段时间里，我也是在混乱中组织模块目录结构，直到后来看了一个国外文章的分析，才开始逐渐建立规范。

现在介绍几种常见的目录结构，供大家参考。

以下内容部分引用于：How to structure your modules directory

1. 经典目录结构

|--sites
|  |-- all
|  |   |-- modules
|  |   |-- themes
|  |-- example.com
|  |   |-- modules
|  |   |-- themes
|  |-- default
|  |   |-- modules
|  |   |-- themes

优点：这是经典的模块目录结构，也是drupal在建立多站时的优点，不同的子站可以共享一些相同的模块，达到节约空间，提升速度（php opcode缓存可以占用更少）。

缺点：对于单个站，目录过于分散；default经常被druapl设为只读；在代码版本化过程中，有把default下面的其他文件（settings, files）加入版本库的风险（尤其是git经验不足的程序员）。

2. 创建单独的custom目录

|-- sites
|   |-- all
|   |   |-- modules
|   |   |   |-- antispam
|   |   |   |-- custom
|   |   |   |-- cck

优点：模块相对集中；版本化无风险。

缺点：custom目录淹没于contrib模块中，不容易进入；有时候，其他程序员不仔细，会发现不了custom目录，导致把自定义模块放在外面。

3. Custom 和 contrib

|-- sites
|   |-- all
|   |   |-- modules
|   |   |   |-- contrib
|   |   |   |-- custom

优点：这是比较常见的相对好的目录结构，简单明了。

缺点：模块区分相对单一。

4. 理想的目录结构

|-- sites
|   |-- all
|   |   |-- modules
|   |   |   |-- contrib
|   |   |   |-- custom
|   |   |   |-- dev-tools
|   |   |   |-- patches
|   |   |   |-- migration

优点：模块区分层次分明，contrib放第三方模块，custom放自定义模块，dev-tools放开发类模块（如devel，不用上生产环境的，即使上了也可以轻松找到并禁用），patches放补丁（通常里面还有一个readme来记录补丁操作），migration放置数据迁移的一些中间文件（如csv，xml，img）。

缺点：需要大家去习惯，并使规范。

补充：有些人会问features怎么放比较好？features的导入导出非常频繁，还有很多把features代码和自己的代码合并，所以features可以归入到custom目录。