我认为这里有一点脱节——至少,术语脱节足以使解析大量有关 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 开始变得困难。