2

我在学习 Drupal 时遇到的一件事就是管理输出。模板中有这样一个抽象。所有的输出——所有的模板，真的——都是从界面完成的。您无需编写标记代码，而是放置块并创建视图。并且您必须为您想要的特定输出拥有正确的块或视图。

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

例子：

我希望为某种内容类型显示某个菜单。我没有在其中插入此菜单的那种类型的模板文件，而是找到一个可能输出我想要的内容的块，配置它（并希望它配置我想要的方式），放置它在全局位置，然后将其限制为仅显示某些内容类型。

这与大多数其他 CMS 有很大的不同。正如我之前所说，真的没有......模板。这都是配置，作为开发人员，我发现这真的非常麻烦。我正在浏览所有这些管理屏幕，并尝试对块进行详细配置，并且一直在想，“如果我能得到标记，我可以在 30 秒内解决这个问题......”

这种异化的解决办法是什么？我只需要硬着头皮接受哲学吗？我是否开始编写自己的主题——这会带我回到更熟悉的环境吗？来自更“传统”模板环境的其他开发人员如何处理这个问题？

我只是想在这里了解大局。

4

1 回答 1

2

我认为这里有一点脱节——至少，术语脱节足以使解析大量有关 Drupal 主题系统的现有公共文档变得困难。

从技术上讲， Drupal 的所有输出都是模板化的。除了少数例外（例如，指向用户用户名的链接），每一位标记都位于模块或当前主题提供的 foo-bar.tpl.php 样式模板文件中。Drupal 模块构建数据，然后将其传递到模板中以生成 HMTL。在实践中，每个模板的输出都嵌套在下一个模板中，就像一组俄罗斯套娃一样。例如：

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。数据被推入趣味工厂，主题系统通过模板将其挤压以产生有趣的形状。

长话短说，可以将导航菜单等内容塞入单独的模板中。但是记住嵌套系统很重要——node.tpl.php模板只控制包含单个帖子的标记片段，而不是围绕它的包装器或包含它的页面。如果不编写自定义代码，page.tpl.php模板不知道其各个区域内的内容；它只知道如何将它们包装在正确的容器 div 中。

整个方法可以非常非常容易地放入各种插件模块，这些插件模块向页面添加额外的位，有条件地响应正在显示的内容等等，而无需每次触摸模板本身——因为它们只是控制每个微小元素的方式呈现，以及连接的聚合如何包装在包含标记中。另一方面，对于习惯于构建完整模板并从 CMS 中提取有用的部分来填充它的人来说，这种方法也可能令人抓狂。Drupal 的“构建内容，然后通过模板推送”方法与许多其他系统使用的“构建模板并将内容拉入其中”方法不匹配。

有各种模块，如面板，允许站点构建者对页面、布局等采取更全面的方法，但它仍然使用相同的嵌套模板方法，这会使从 HTML 开始变得困难。

于 2013-05-27T02:41:17.270 回答