kolidon原作于2009年9月24日

1. 模板一致性
此问题并不是指模板风格和CSS一致，虽然这也很重要但是并不困难。Drupal中模板的问题在于因为系统模板的灵活，模板很难集中控制。即，模块中代码未模板化，或模板置于多个目录位置。

习惯以自有框架特别是某一种特定模板方案比如smarty一类，并且对模板进行集中处理的团队，转入Drupal后往往会对此迷惑。

实际上，这个问题是一个技术问题。

实施中解决办法是：制定出团队自己的模板命名，控制规范并不断修订完善。在每个项目中，对模板、自定义模板函数、自定模块中的模板以表格视图进行跟踪。

虽然Drupal系统提供了大量可能的模板化实施可能性，但对此系统了解越多，越能发现最简单的往往是最可靠的：仅使用模块内模板结构+模板目录内统一控制。

2. CCK及Views的使用

我们发现，基本上所有情况下Views殾能满足我们的需求——如果善用其Api文档的话，kolidon所在团队亦在学习如何将更多block也Views化——当然是不是一些其他页面也Panel化就有待考虑了（因为莫须有的性能问题）。

但我们偶尔会需要添加自定义的扩展模块来对其功能进行更改或扩展。

3. 权限问题

我们有时会需要在term页列出所有文章及其teaser但一个常用模块Content Access可能阻止那些无权限的文章出现在此页面，而此模块可能在其他页面会能用到（当然若不使用此模块此处不会用问题但会对项目其他需求造成不便）。

此时我们常做的时完全放开此content type的权限改由自定义模块来控制其全文存取。

4. Input format

输入格式对不同roles的授权也是需要较长时间试验才能获得满意结果的位置。

5. 开源模块质量

开源模块并非拿来就能用，最好看看其是否对性能造带来多大问题：比如某个模块og content admin就可能是一场华丽的性能灾难。

6. Menu及Breadcrumb系统

这个不用说，在任何系统中都是重中之重。若你使用了大量的第三方模块，然后又使用了大量的自定义模块，然后又企盼能将它们无缝组合起来：指的是在外部表现、菜单和Breadcrumb上的完全按业务需求而非模块的目录和自命名结构，那么，多考查几种相关模块，再多花点时间反复试验以便最终熟练吧。

7. 请尊重garland模板

这套模板，实际上，已经帮助我们完成了任何自定义模板工作的80%。所剩的唯有考查是否需要新增area，对原style.css作何种重规划和改进了。但对其整体结构的改变，试过后才会知道，意义不大。

8. locale问题

多语言在任何系统中都会是一个问题，kolidon并不认为Drupal在解决此问题上就已经完美了。

如果你仅仅是需要开发一种特定语言的系统，那么事情不会特别复杂（虽然也会出现一些莫名其妙的问题需要耗费大量时间去调试，比如关闭原生的English时你会发现部分页面会变成blank）。若需要开发多语言而且需要它们能正常切换，那么，诸天神佛保佑，但愿你的团队中有人研究过所有源代码，对这一部分的系统实际有深入了解并随时愿意解决各第三方模块中可能出现的语言问题。

9. Messaging和Notification

这部分也很好玩，如果你花了很多精力玩转了的话，另外，当然Cron不会是一个大问题但同样需要我们保持关注。但是当Messaging、Notification与Locale问题纠缠在一起，特别是不同的用户需要不同的Messaging的时候，我不知道它们是不是仍然让人喜欢。:-)

10. JS问题

如果团队中没有人精通JS，那么至少需要了解Jquery的用法和Drupal的JS框架。上天保佑，这么多Js不会产生冲突。

11. 性能问题

这个实际上如果没有太变态的第三方块的话，不会有什么问题，但若对性能要求较高的话，在登录状态，会需要所有人来贡献智慧以便解决周边的性能问题比如数据库、Gzip压缩、图片大小、背景图片或装饰图片数字，Js性能等等。最后，你会发现，转了一圈，回来了——我们终将面对的是登录状态下的Drupal核心的性能问题。若到了这一步，基本上，团队就开始专业起来了。