理想情况下，在通过主题或插件自定义 Discourse 时，您应使用 CSS、JavaScript 插件 API 或 插件出口 。如果这些方法都不适用于您的用例，请随时向 Discourse 核心提交 PR，或在此处的 Meta 上发起一个 Development
如果您已穷尽所有其他选项，可能不得不采用模板覆盖技术。该技术允许您从主题或插件中覆盖任何 Ember 组件或路由的完整模板。
这不是推荐的自定义 Discourse 的方式。 Discourse 核心的日常变更 最终 会与您的模板覆盖发生冲突，可能导致论坛渲染时出现灾难性错误。
如果您决定采用这种方法，请确保您拥有足够的自动化测试和质量保证流程来检测回归问题。如果您分发了包含模板覆盖的主题或插件，请务必让论坛管理员了解该主题或插件带来的稳定性风险。
2023 年 10 月更新 ：对于新功能，Discourse 正越来越多地采用使用 Ember 的 .gjs 文件格式编写的组件。这些组件的模板是内联定义的，无法被主题或插件覆盖。
今后，所有模板自定义都应使用 插件出口 进行。
我理解这将在不久的将来失效，但仍请向我展示文档
要覆盖 Ember 组件模板（即 Discourse 核心中 components/*.hbs 文件。例如，要覆盖 Discourse 核心中的 badge-button 组件模板，您需要在主题或插件中的以下位置创建模板文件：
{theme}/javascripts/discourse/templates/components/badge-button.hbs
{plugin}/assets/javascripts/discourse/templates/components/badge-button.hbs
覆盖文件必须始终嵌套在 /templates 目录内，即使核心组件使用的是“共置”模板。
覆盖路由模板（即 templates/*discovery.hbs，您可以创建如下文件：
{theme}/javascripts/discourse/templates/discovery.hbs
{plugin}/assets/javascripts/discourse/templates/discovery.hbs
如果多个已安装的主题或插件覆盖了同一模板，则“胜出者”是以下列表中排名最低（数字最小）的一个：
主题覆盖（主题 ID 最大的获胜）
插件覆盖（按字母顺序排列的最新插件名称获胜）
核心
这种优先级也意味着您可以从主题中覆盖插件模板。从技术上讲，您甚至可以从其他主题覆盖主题模板，或从其他插件覆盖插件模板，但由于依赖于插件名称和主题 ID，其行为可能会令人意外。
Discourse 在 DiscourseTemplateMap 类中组装并优先处理模板。对于共置的组件模板，该信息用于 应用初始化期间 替换核心模板关联。对于所有其他模板，该映射由 运行时的解析器 使用，以获取正确的模板。
本文档受版本控制 - 请在 GitHub 上提出修改建议。
17 个赞
david
2022 年12 月 7 日 15:47
3
它应该完全一样——你匹配核心模板的名称。因此，如果它有 /mobile，请将其包含在你的覆盖中。
misham
2022 年12 月 14 日 10:42
4
我尝试重写 mobile login.hbs 模板，但它不起作用 Imgur: The magic of the Internet
david
2022 年12 月 14 日 11:18
5
据我所见，您的截图中未显示完整路径。请在此处将其粘贴为文本。
misham
2022 年12 月 14 日 12:00
6
themeroot/javascripts/mobile/modal/login.hbs
david
2022 年12 月 14 日 12:03
7
您的路径中缺少 discourse/templates
因此，在您的情况下，它将是 {theme}/javascripts/discourse/templates/mobile/modal/login.hbs
2 个赞
这种情况现在还存在吗？
我有点难过能够覆盖大量代码的功能被移除了。
用 Glimmer 替换定制的 Widget 系统在某种程度上是有意义的，但 Widget 系统让我们能够深入到多个层级来挂钩现有代码，通过巧妙地定位小的代码块来降低很多破坏性更改的风险，使我们能够：
例如，我刚刚不得不从 Discourse Journal 中删除两个重要的功能，它们是基于对 Widget 的细粒度覆盖来实现的，因为在 Glimmer 中重新创建它们的唯一方法是通过一对模板覆盖（包括尝试更改 .gjs 文件），而这似乎不再受支持。
即使支持，我们也只能覆盖比 Widget 框架更大的代码块，这会增加核心更改与覆盖冲突的风险。
这对平台的扩展性不利。
有什么办法可以解决这个问题吗？
7 个赞
david
2024 年3 月 7 日 13:17
13
是的，我明白你的意思——小部件可扩展性 API 有一些很好的地方。
但另一方面，我们很难修改核心中的任何基于小部件的用户界面，因为我们不知道人们可能会引入哪些随机方法/装饰。这就是为什么小部件自定义似乎相对稳定——我们太害怕触碰核心实现。
Robert:
我们可以巧妙地只针对一小块
我们未来的解决方案是Wrapper Plugin Outlets 。这些允许主题和插件使用自己的实现可选地覆盖非常小的模板块。
例如，看看 Chat 如何有条件地覆盖 home-logo 与自定义组件 。这适用于现有的基于小部件的标题，以及新的基于 Glimmer 的标题（即将推出！
我们通常乐于接受在各种地方添加新的 wrapper outlets 的 PR。如果您不确定某个特定用例，请随时使用 Dev
10 个赞
这不是推荐的自定义 Discourse 的方式。 Discourse 核心的日常变更 最终 会与您的模板覆盖发生冲突，可能导致论坛渲染时出现灾难性错误。
）