(不推荐)从主题或插件覆盖 Discourse 模板

理想情况下,在通过主题/插件定制 Discourse 时,应使用 CSS、JavaScript 插件 API插件出口(Plugin Outlets)。如果这些方法都不适用于您的使用场景,请随时向 Discourse 核心提交 PR,或在此处的 Meta 上发起一个 Development 主题。我们总是乐于讨论添加新的出口/API,以使定制变得更加容易。

如果您已经穷尽了所有其他选择,可能需要诉诸于模板覆盖(template overrides)。这种技术允许您从您的主题/插件中覆盖任何 Ember 组件或路由的整个模板。

:rotating_light: 这不是定制 Discourse 的推荐方式。 Discourse 核心中的日常变更最终会与您的模板覆盖发生冲突,可能会导致渲染论坛时出现灾难性的错误。

如果您决定采用这种方法,请确保您拥有足够的自动化测试和 QA 流程来检测回归问题。如果您分发的主题/插件包含模板覆盖,请确保论坛管理员了解您的主题/插件所携带的稳定性风险。

:rotating_light: :rotating_light: :rotating_light: 2023 年 10 月更新:对于新功能,Discourse 正越来越多地转向使用 Ember 的 .gjs 文件格式编写的组件。这些组件的模板是内联定义的,无法通过主题/插件进行覆盖。

今后,所有模板定制都应使用 Plugin Outlets 来完成。

我知道这很快会失效,但还是给我看文档

覆盖组件模板

要覆盖 Ember 组件的模板(即 Discourse 核心中 components/* 下的任何内容),您应该在您的主题/插件中创建一个同名 .hbs 文件。例如,要覆盖 Discourse 核心中 badge-button 组件的模板,您需要在主题/插件中的以下位置创建一个模板文件:

:art: {theme}/javascripts/discourse/templates/components/badge-button.hbs

:electric_plug: {plugin}/assets/javascripts/discourse/templates/components/badge-button.hbs

即使核心组件具有“共置”(colocated)模板,覆盖文件也必须始终嵌套在 /templates 目录内。

覆盖路由模板

覆盖路由模板(即 templates/* 下的所有非组件模板)的方式与组件相同。在您的主题/插件中创建一个同名模板。例如,要覆盖核心中的 discovery.hbs,您需要创建一个如下所示的文件:

:art: {theme}/javascripts/discourse/templates/discovery.hbs

:electric_plug: {plugin}/assets/javascripts/discourse/templates/discovery.hbs

多个主题/插件之间的交互

如果多个已安装的主题/插件覆盖了同一个模板,“获胜者”是以下列表中排名编号最低的那个:

  1. 主题覆盖(具有最高主题 ‘id’ 的主题获胜)
  2. 插件覆盖(字母顺序最新的插件名称获胜)
  3. 核心

这种优先级还意味着您可以从主题中覆盖插件模板。从技术上讲,您也可以从其他主题中覆盖主题模板,从其他插件中覆盖插件模板,但由于依赖于插件名称和主题 ID,其行为可能会令人惊讶。

这是如何工作的?

Discourse 在 DiscourseTemplateMap 类中组装并优先处理模板。对于共置的组件模板,该信息在 应用程序初始化期间 用于替换核心模板关联。对于所有其他模板,该映射由 运行时解析器 用于获取正确的模板。


本文档受版本控制 - 请在 github 上建议更改。

17 个赞

移动模板呢?重写核心模板的目录结构是什么?

它应该完全一样——你匹配核心模板的名称。因此,如果它有 /mobile,请将其包含在你的覆盖中。

我尝试重写 mobile login.hbs 模板,但它不起作用 Imgur: The magic of the Internet

据我所见,您的截图中未显示完整路径。请在此处将其粘贴为文本。

themeroot/javascripts/mobile/modal/login.hbs

您的路径中缺少 discourse/templates

因此,在您的情况下,它将是 {theme}/javascripts/discourse/templates/mobile/modal/login.hbs

2 个赞

这种情况现在还存在吗?

我有点难过能够覆盖大量代码的功能被移除了。

用 Glimmer 替换定制的 Widget 系统在某种程度上是有意义的,但 Widget 系统让我们能够深入到多个层级来挂钩现有代码,通过巧妙地定位小的代码块来降低很多破坏性更改的风险,使我们能够:

  • 添加功能
  • 不干扰其他任何东西。

例如,我刚刚不得不从 Discourse Journal 中删除两个重要的功能,它们是基于对 Widget 的细粒度覆盖来实现的,因为在 Glimmer 中重新创建它们的唯一方法是通过一对模板覆盖(包括尝试更改 .gjs 文件),而这似乎不再受支持。

即使支持,我们也只能覆盖比 Widget 框架更大的代码块,这会增加核心更改与覆盖冲突的风险。

这对平台的扩展性不利。

有什么办法可以解决这个问题吗?

7 个赞

是的,我明白你的意思——小部件可扩展性 API 有一些很好的地方。

但另一方面,我们很难修改核心中的任何基于小部件的用户界面,因为我们不知道人们可能会引入哪些随机方法/装饰。这就是为什么小部件自定义似乎相对稳定——我们太害怕触碰核心实现。

我们未来的解决方案是Wrapper Plugin Outlets。这些允许主题和插件使用自己的实现可选地覆盖非常小的模板块。

例如,看看 Chat 如何有条件地覆盖 home-logo自定义组件。这适用于现有的基于小部件的标题,以及新的基于 Glimmer 的标题(即将推出!:tm:

我们通常乐于接受在各种地方添加新的 wrapper outlets 的 PR。如果您不确定某个特定用例,请随时使用 Dev 主题发布详细信息!

10 个赞

好的,这听起来是个可行的方案,谢谢你。

我需要消化一下它的影响,并据此调整策略。

感谢你的回复!

6 个赞