每个 Drupal 站点都会用到一定数量的模块，养成良好的模块组织习惯非常重要，尤其以团队进行某一个项目时，规范的模块目录组织结构能够使站点的开发和维护变得更加容易。经过长时间的项目积累与验证，今天与大家分享一下模块目录结构的组织方式：; a) ^3 ^6 h7 G5 W9 h
; ~% {9 P/ z3 I" _ k# u9 m8 W
sites/all/modules/contrib4 W+ T e) \3 M1 }: e
sites/all/modules/custom
0 d+ d* j. `. W3 T0 u' d% {sites/all/modules/[project_name]
( p6 n7 g% f# ~8 X) y2 @+ Y4 x; {3 Fsites/all/modules/dev6 g9 v$ }& C8 C9 o
8 o, Q# q/ `$ k4 I& v# C
模块位置的基本原则/ W2 ^( S+ y4 g- \3 v/ H4 Z
按照惯例，所有非核心的 Drupal 模块都应该放置于 sites 目录下，这样在将来对 Drupal 版本进行升级时才会方便。
. j; f( O7 L4 u. n
9 Y' B' m {7 p- g2 a分目录组织模块5 X! S& w, N" P) o& j- C D9 C4 R
从上面的目录结构可以看出，我们将模块目录分为第三方模块、自定义模块、项目模块和开发辅助模块。
, s S4 J0 g7 ]: w" T0 L1 g) J2 v) G
“第三方模块”是指我们从 Drupal 官网上下载下来的模块，一般而言，我们不会也不推荐修改这些模块。因此将这类模块存放于 contrib 目录进行集中管理。' `5 c# u7 t6 i4 A( v e, `$ r
. r. B5 e. w8 U* y4 Y5 O$ a
“自定义模块”目录用于存放我们自己创建的通用模块—“通用”是指这个模块拿出来放到其它的Drupal网站也能用，“自定义模块”与“第三方模块”的区别可能只在于能不能通过 drupal.org 进行下载。“自定义模块”目录的另一个作用是存放我们改动某个第三方模块（虽然不推荐个性第三方模块，但有时还是不得不修改它们才便于实现某些功能），那么我们建议将改动的第三方模块移动到 custom 目录下，这样一来，在对模块进行升级前我们会记得对这个模块进行了修改，就可以在升级前制作补丁而避免升级覆盖了修改。
- H `7 \. c9 M8 } v% ?, A0 L4 S& V+ D _* ]. `
“项目模块”目录下的模块也属于自定义模块，不同点在于这个目录下的模块是针对某一个项目的特定模块，不具备通用性。除了自定义模块，使用 features 模块导出的针对当前项目的各种功能包也应该放在此目录下。+ X% A) I' W0 q
, Y4 H5 d6 w2 I1 v3 m4 @7 ~# Z
“开发模块”目录则用于存放各个作为开发用途的模块。
, r, y! y/ ~$ g9 q0 _ ^8 C/ u0 t3 o4 a+ p4 }
单独存放开发辅助模块3 r: d" t( m6 t( n0 U6 b
在制作 Drupal 站点的过程中，少不了使用各种开发辅助模块，如 devel, devel_themer, demo, simpletest, trace 等等。这些模块对于开发过程非常有帮助，但如果放到生产服务器和测试服务器则不太合适，还会产生不少安全隐患。因此将这些模块单独存放在 dev 目录下，同时也不应该被 git 或其它版本控制软件跟踪，让它们只存在于每个开发人员的开发环境下，即轻便又安全。
8 {+ e- }( `% G/ k% u
# c; i5 C% _4 |5 n7 ^8 [7 y( U! d0 r. I! f- E
本文选择： lugir，谢谢！! V; u6 D0 W J- n) g8 Q5 [
|
|
发表于 8-24-2012 18:36