在最新版本的 Discourse 中，在主题和插件中使用 .hbs 文件已被弃用。对这种文件格式的支持将在下一次 ESR 版本发布后移除。
Handlebars 模板应替换为更现代的 .gjs 格式，这提供了更好的开发体验，并将在未来版本的 Discourse 中实现显著的性能提升。
对于简单的情况，请与 https://ask.discourse.com/ 分享您的代码，并请它重写为 .gjs 格式。
对于更复杂的情况，可以使用此代码转换器自动更新：
我理解正确吗？2026.7 版本仍然支持 hbs 文件，而 2027.1 将是第一个不支持 hbs 文件的 ESR 版本？
是的，完全正确。
我们很有可能在 2026.8.0-latest 中停止支持。但这可能稍晚一些，具体取决于实际数据和社区的反馈。
刚看到这个，估计需要更新了
谢谢！希望大多数人已经处理了这些，因为管理员横幅已经弃用了它们将近一年了。只是以防万一，我添加了这条注释：
就我个人而言，我为我个人的小插件尝试了一下，并在 ask Discourse 的帮助下成功了，它将我的 hbs 文件和 js 文件合并成一个 gjs 文件。
我强烈建议像我一样有开发困难的人使用 ask Discourse 来解决这个问题 
太棒了！我也在原帖中添加了关于 ask.discourse.com 的说明。如果只有少量文件，这会非常有效 
我完全不知道 .gjs 文件是什么，也没有时间去学习它并重写多个插件。这太荒谬了。
如果插件 API 像 Discourse 中那样脆弱，那设置插件 API 还有什么意义？维护这个论坛软件的插件一直麻烦不断。
这绝非荒谬。
如果您没有足够的预算或带宽来管理自定义功能，我建议您简化您的设置。
在我看来，这是为了继续使用一个处于前沿、高速迭代、持续创新、不断优化性能、频繁部署安全补丁并紧跟不断演进的标准的平台而需要付出的（合理）代价。
Discourse 团队似乎投入了大量精力，确保在功能被弃用之前很久就会发出弃用警告。
您是否宁愿被困在一个不安全且功能较少的平台上？
请想想您从那个可以免费下载且维护良好的核心中所获得的价值。
你甚至不必知道 .gjs 文件是什么：Automatically updating themes and plugins to .gjs file format
这对我的小插件不起作用。
但在 ask.discourse.com 的帮助下，他阅读了我的代码，并将我的 .hbs 和 .js 文件转换成了 .gjs 格式。因此，如果第一种方法行不通，请不要犹豫。
我认为这个问题之前也在这里得到过解答：
另外，
请注意，我理解你的沮丧情绪。所有在这里开发插件、主题或组件的人都面临着功能弃用和强制更新的问题。
还有一些人也表达了类似的沮丧：
我不再对我的任何 Discourse 插件进行任何后续开发。这已经不值得了。
鉴于其他人正在使用其中的两个插件，删除它们而不给他人带来问题的流程是什么？
我受够了它们每隔几个月就因各种毫无道理的原因而失效，以及为了维持我的论坛正常运行所耗费的大量时间和精力。
我不想“站在技术前沿”。我只需要一个能正常工作、稳定的网络论坛。
“不要更新”也不是一个可行的选项，因为我们需要安全更新。上次我抱怨时，竟然有人建议这样做，这简直荒谬。
Discourse 团队真的需要更加关注兼容性问题，避免破坏现有的论坛和代码。他们似乎根本没有考虑过这一点。他们为了在自己这边稍微整理一下，就进行破坏性变更。这不是管理一个被他人使用的平台和 API 应有的方式，我不想再参与其中了。
听到这个消息我很难过！
如果您确实打算走这条路，我建议在 README 和 Meta 主题中添一条备注，将其标记为 broken，然后归档 GitHub 仓库。这样，其他人仍然可以 fork 它（假设许可证足够宽松）。
我们绝对重视兼容性并确保一切正常运行。这就是为什么我们设有较长的弃用周期，并提供完全自动化的升级路径。
我们始终努力在可定制性和稳定性之间取得平衡——Discourse 主题和插件之所以如此强大，正是因为我们赋予了它们直接访问底层浏览器/框架 API 的能力。这种巨大的能力也伴随着一定的责任，即需要跟上底层的变化。
确实如此——保持更新非常重要。在过去的几个月里，我们大力投入了发布流程，以更好地服务于 ESR（之前称为“稳定版”）用户。更多详情请在此查看。您仍然需要更新，但在更新的时机和紧迫性方面有了更大的灵活性。
至于这次具体的弃用，解决方案是完全自动化的。如果您能告知我们插件的名称，我们很乐意为您运行代码转换工具并提交 PR。我们已经为我们维护的 600 多个主题/插件完成了这项工作，因此现在这已经是一套非常成熟的流程了。
在这篇帖子中，我提议添加 unmaintained（不再维护）标签或 end-of-life（生命周期结束）标签。
我理解，如果几个月后有人回来，发现已有大量变更，这并不容易。跟上这些变化可能并不轻松，但在我看来，这是使用一款拥有广泛 API 的前沿论坛软件所必须付出的代价。
那么，为什么你们总是为了清理自己这边的一些次要“垃圾代码”，而牺牲兼容性不断做出更改呢？
那些遗留的“垃圾代码”是维护平台或 API 所必须付出的代价。它们实际上并不会造成真正的问题。但你们却坚持要更改或删除它们，导致其他人不得不进行额外的工作和测试。
ESR 版本仅支持 9 个月，这几乎算不上是扩展支持。
而且使用这些版本只会意味着你们必须一次性应对所有破坏性变更，如果试图排查问题原因，需要搜索的提交记录列表也会变得非常庞大。
以目前的状况来看，ESR 只会让这个问题变得更糟，而不是更好。
唯一的解决方案是真正重视 API 并对其进行维护。将破坏性变更作为最后手段，而不是为了“锦上添花”的小修小补。也不要仅仅因为你们想用另一个框架，或者出于其他任何原因，就彻底抛弃人们正在使用的整个框架。
这里的流程是：生产环境使用 ESR 版本，而测试环境（staging）使用月度发布版本或已通过的测试版本。
如果你每天/每周/每月更新测试环境——甚至可以实现自动化——你就可以逐步更新插件和主题，并确保它们始终处于可用状态。
生产环境继续使用 ESR 版本的事实，至少能为你争取三个月的缓冲时间来修复问题。
你似乎无法理解这样一个概念：已发布的 API 不应成为一个不断变动的目标。
试想一下，如果微软要求所有 Windows 开发者每六个月就修改一次他们的代码，那简直是不可想象的。你可以将 30 年前为 Windows 95 编写的代码，在现代机器上直接编译并运行，无需任何修改。
当你声称关心兼容性时，却因你自己做出的决定，导致按照你的规范编写的代码完全无法运行，这显然是自相矛盾的。
Windows 掌控其整个技术栈，而 Discourse 是在一个活跃的生态系统之上构建平台。仅 Ember 就在多个主版本中多次破坏向后兼容性。而这在前端生态系统中是常态，而非例外。
在我看来，这里正确的模式显然不是 Windows 模式，而是其他 API 平台所采用的做法：清晰的版本管理、弃用通知以及合理的迁移窗口。