我在学习Drupal时遇到的一件事就是管理输出。从模板中得到了这样的抽象。所有输出 - 所有模板，真的 - 都是从界面完成的。您不编码标记，放置块并创建视图。并且您必须拥有所需特定输出的正确块或视图。
将此与大多数其他CMS形成对比，您可以在其中使用一些模板库，并在HTML标记中嵌入令牌（或代码 - 实际或模板特定的）。在Drupal中似乎没有任何一个。
示例：
我希望针对特定内容类型显示某个菜单。我没有为我刚刚插入此菜单的那种类型的模板文件，而是找到一个可能输出我想要的块，配置它的地狱（并希望它配置我想要的方式），放置它在全球范围内，然后将其限制为仅显示某些内容类型。
这与其他大多数CMS相差无几。正如我之前所说，真的没有......模板化。这是所有配置，作为开发人员，我发现这真的非常麻烦。我正在浏览所有这些管理屏幕，并尝试精确配置一个块，并且我一直在想，“如果我能够得到标记，我可以在30秒内解决这个问题......” / p>
这种异化的解决方案是什么？我只需要咬紧牙关并接受这一理念吗？我是否开始编写自己的主题 - 这会让我回到更熟悉的环境吗？来自更“传统”模板环境的其他开发人员如何处理这个？
我只想在这里了解全局。
答案 0 :(得分：2)
我认为这里存在断开连接的位 - 至少，足够的术语断开，使得很难解析很多关于Drupal主题系统的现有公共文档。
从技术上讲，Drupal输出的所有都是模板化的。除了少数例外（例如，指向用户用户名的链接），每个标记位都位于由模块或当前主题提供的foo-bar.tpl.php样式模板文件中。 Drupal模块构建数据，然后将其传递到模板中以生成HMTL。实际上，每个模板的输出都嵌套在下一个模板中，就像一套Matryoshka娃娃。例如：
html.tpl.php (the HTML wrapper)
page.tpl.php (everything inside the body tag)
region.tpl.php (the 'main content' portion of the page)
node.tpl.php (post in the main content)
field.tpl.php (the post's "related links" field)
field.tpl.php被渲染，并与所有其他字段连接，然后聚合HTML成为一个变量，传递到node.tpl.php模板并包装在其他标记中，然后作为哑HTML传递进入region.tpl.php ......好吧，你明白了。好消息是，您可以向下钻取并选择一小部分标记，并在整个站点范围内进行修改。坏消息是，有数千个小模板用于构成页面的各个标记位。
对象本身的嵌套由Drupal的配置系统指定，但模板本身仍然控制实际的HTML输出。如果主题开发人员想要，他们可以将传统的PHP应用程序转储到html.tpl.php并执行 - 当菜单路由系统请求页面时执行Drupal的代码但完全忽略输出它是在打印页面时生成的。
从本质上讲，整个系统就像Play-Do Fun Factory一样。数据被推入Fun Factory，主题系统通过模板挤压它以产生有趣的形状。
长话短说， 可能会将导航菜单等内容堵塞到各个模板中。但是记住嵌套系统很重要 - node.tpl.php模板只控制包含单个帖子的标记片段，而不是它周围的包装器或包含它的页面。在不编写自定义代码的情况下，page.tpl.php模板不知道里面的各个区域是什么;它只知道如何将它们包装在正确的容器div中。
整个方法使得非常，非常容易地放入各种插件模块，为页面添加额外的位，有条件地响应显示的内容，等等，而不是每次触摸模板本身 - 因为他们只是控制每个呈现微小元素，以及如何在包含标记的情况下包装连接聚合。另一方面，对于习惯于构建完整模板并从CMS中提取有用位以填充它的人来说，这种方法也会令人抓狂。 Drupal的“构建内容，然后通过模板推送”方法与“构建模板并将内容拉入其中”不符合许多其他系统使用的方法。
像Panel这样的各种模块允许网站构建者对页面，其布局等采取更全面的方法，但它仍然使用相同的嵌套模板方法，可以从HTML开始。< / p>