CMS开发人员如何使用“传统”模板学习如何爱Drupal？

Question

我在学习Drupal时遇到的一件事是管理输出。有这样一个模板抽象。所有的输出 - 所有的模板，实际上都是从接口完成的。你不编码标记，你放置块和创建视图。而且你必须有正确的块或视图来获得你想要的特定输出。

将此与大多数其他CMS进行对比，其中您有一些模板库，并且在HTML标记中嵌入了令牌（或代码 - 实际的或模板特定的）。在Drupal中似乎没有任何内容。

例子：

我想一定菜单出现了一定的内容类型。我没有为这种类型的模板文件插入这个菜单，而是找到一个可以输出我想要的块的模块，并将其配置为它（并希望它配置了我想要的模式），将它放置在全球范围内，然后将其限制为仅显示某些内容类型。

这是一个非常大的偏离大多数其他CMS。正如我之前所说的，真的没有...模板。这都是配置，作为开发人员，我觉得这真的很麻烦。我正在浏览所有这些管理屏幕，并试图精心配置一个区块，并且始终在思考：“如果我能够加入标记，我可以在30秒内解决这个问题......”

这种异化的解决方案是什么？我只需要咬紧牙关，接受哲学呢？我是否开始写自己的主题 - 这会让我回到更熟悉的环境吗？来自更多“传统”模板环境的其他开发人员如何处理此问题？

我只是想在这里看到大图。

Answer 1

我认为这里有一个位断开连接 - 至少有足够的术语断开连接，导致很难解析大量关于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的“构建东西，然后通过模板推送”方法与许多其他系统使用的“构建模板并将其引入其中”方法不匹配。

有许多模块可以让站点构建者对页面及其布局等采取更全面的方法，但它仍然使用相同的嵌套模板方法，可以从HTML开始。