每个 Drupal 站点都会用到一定数量的模块,养成良好的模块组织习惯非常重要,尤其以团队进行某一个项目时,规范的模块目录组织结构能够使站点的开发和维护变得更加容易。经过长时间的项目积累与验证,今天与大家分享一下模块目录结构的组织方式:
- [5 I" I1 p' M+ w" @: E, T
+ D$ ~! ?8 ^( Ysites/all/modules/contrib4 [, `4 n" J2 s
sites/all/modules/custom
8 X9 |7 w3 s9 V- j- Jsites/all/modules/[project_name]
$ @% a: r+ Q' q+ esites/all/modules/dev/ r6 v! a: M1 G4 u
1 K+ f; q& C& w6 g模块位置的基本原则 ~6 l/ @# V2 E+ n5 t! t
按照惯例,所有非核心的 Drupal 模块都应该放置于 sites 目录下,这样在将来对 Drupal 版本进行升级时才会方便。
! ]6 \2 h- e' J8 ~3 S( c
( R7 _: ], g; J8 Q( ^% }! N, c分目录组织模块# u3 M* g$ k7 y! k- h+ j. M# r
从上面的目录结构可以看出,我们将模块目录分为第三方模块、自定义模块、项目模块和开发辅助模块。$ q; ~ R0 ^3 y" n. Z9 G
- C4 S: M- A( r; z
“第三方模块”是指我们从 Drupal 官网上下载下来的模块,一般而言,我们不会也不推荐修改这些模块。因此将这类模块存放于 contrib 目录进行集中管理。) V5 Q! N5 W0 k- H3 c# w! w9 H
: S- ~) z3 x' f: d( i" E- I
“自定义模块”目录用于存放我们自己创建的通用模块—“通用”是指这个模块拿出来放到其它的Drupal网站也能用,“自定义模块”与“第三方模块”的区别可能只在于能不能通过 drupal.org 进行下载。“自定义模块”目录的另一个作用是存放我们改动某个第三方模块(虽然不推荐个性第三方模块,但有时还是不得不修改它们才便于实现某些功能),那么我们建议将改动的第三方模块移动到 custom 目录下,这样一来,在对模块进行升级前我们会记得对这个模块进行了修改,就可以在升级前制作补丁而避免升级覆盖了修改。
! @, N, C; \8 B# g* j& z; e6 o$ Q( L% P d, r7 |
“项目模块”目录下的模块也属于自定义模块,不同点在于这个目录下的模块是针对某一个项目的特定模块,不具备通用性。除了自定义模块,使用 features 模块导出的针对当前项目的各种功能包也应该放在此目录下。$ r% C j# [2 i# e" Y: Y3 K$ k
' ?" j# h0 o8 g3 D$ w- B( q
“开发模块”目录则用于存放各个作为开发用途的模块。/ l5 m* n0 T" n0 T
) o6 _( E5 a9 ?" l7 S+ A7 g
单独存放开发辅助模块; t- A8 l1 l. q. q
在制作 Drupal 站点的过程中,少不了使用各种开发辅助模块,如 devel, devel_themer, demo, simpletest, trace 等等。这些模块对于开发过程非常有帮助,但如果放到生产服务器和测试服务器则不太合适,还会产生不少安全隐患。因此将这些模块单独存放在 dev 目录下,同时也不应该被 git 或其它版本控制软件跟踪,让它们只存在于每个开发人员的开发环境下,即轻便又安全。
0 T% i# q: }4 c6 |7 @* ]+ v3 }" y/ e0 x7 _
% }, D2 q1 K- B( L9 u本文选择: lugir,谢谢!
3 o; b* f+ h* B- [ |
|