将更多热门插件与 Discourse 核心打包

公告
1

在接下来的几周内，我们将把一些流行的 Discourse 插件迁移到核心代码库。这意味着 Discourse 将默认包含更多插件，并且我们更容易对它们进行测试和更新。

所有这些插件将保持默认禁用状态，因此不会对现有社区产生任何可见影响。如果您使用 discourse.org 等托管服务，则无需执行任何操作。

自托管社区

如果您自托管 Discourse，并且已经在使用这些插件之一，系统将在您下次重建之前提示您从 app.yml 文件中删除相应的行。

开发环境

如果您已经在本地安装了其中一个插件，然后拉取了 Discourse 核心的最新版本，将会发生以下两种情况之一。

  1. 如果您使用符号链接来管理插件，则在执行 git pull 时会收到错误。要解决此问题，请删除符号链接，然后再次运行 git pull。

  2. 如果您直接克隆插件，则核心的 git pull 会成功，但您会遇到一些由嵌套的 git 存储库引起的意外的“未暂存的更改”。最佳做法是删除受影响的目录，然后从 main 中“恢复”它。例如：

    rm -rf plugins/discourse-reactions
git restore plugins/discourse-reactions

受影响的插件

65 个赞
2

感谢您在帖子开头提供了完整的 HINT 行，这有助于我诊断今天早上重建失败的问题 :blush:

17 个赞
7

谢谢。鉴于我对开发和编程知之甚少，我还是想问您一个问题。这些插件，最初是作为组件添加到基本安装中的，它们有一天会失去插件的特性，成为基本安装的完整一部分，而不再被称为插件吗？

3 个赞
8

是的，他们可能会这样做。特别是，身份验证插件（例如 apple-auth）很有可能会像我们其他的内置身份验证方法（例如 Google、Facebook 等）一样被吸收到核心中。

3 个赞
10

此举将默认情况下进一步促进讨论并方便新安装。

关于以下内容的一个问题：

您的下一次重建之前，系统将提示您从 app.yml 文件中删除相关行。

在点击管理员升级页面上的升级按钮之前/之时，是否也会有提示或警告消息？

3 个赞
11

如果我没记错的话，根据我的经验，你首先只能更新 docker。更新 docker 后，你会在更新 UI 中看到一条消息，解释说你必须通过命令行进行更新，以及如何操作。

然后，当你通过命令行更新时，你会看到第一个帖子中解释的，需要从 app.yml 中删除的每个插件的提示。

4 个赞
12

这次更新不错，但真的有必要吗？给我一个重建失败似乎有点严厉……一个UI警告或自动更新（或者干脆忽略它们）会比给我一把枪说“现在就删除它们”要好得多。

image
image1466×397 48.6 KB

6 个赞
13

这上周把我难住了，当时我尝试通过命令行更新，但失败了（reactions 插件）。

今天早上我的命令行更新再次失败，又把我难住了（data explorer 插件）。

我非常希望在更新过程开始（然后不可避免地失败）之前，命令行能给出一个警告。

现在两周内我的更新已经失败了两次，这意味着我的 Discourse 在我调试问题、编辑配置、重试等等期间都无法访问——而且这一切都伴随着轻微的恐慌，因为一切都坏了。

8 个赞
14

还有另一个问题。

Gem 依赖。

这不仅仅是删除冗余插件克隆的问题。

我们还有 gem 版本冲突的问题。

我正在对我的几个插件中的特定依赖项进行_降级_，因为核心插件落后很多。

所以，依我看，这一举措引入了一些不必要的额外依赖项，并使重建更加脆弱。

3 个赞
15

2 个帖子被拆分到一个新主题：建议改进插件页面，因为现在有更多插件与核心捆绑在一起

17

我们稍后将跟进一项举措，即移除核心插件中的 gem 行，并迁移到单体 gem 文件。

3 个赞
21

我很好奇，您是从实际的 Discourse 安装中获取了这个插件列表吗？它几乎与我自己的主安装匹配了 50%！

2 个赞
22

我想知道，将所有这些插件捆绑在核心中是否会使论坛臃肿？也就是说，可能有一些插件是管理员不希望在他们的论坛上使用的（例如 Discourse AI），但又别无选择只能添加。当然，它可以被禁用，但我担心添加的文件和其他东西会减慢论坛的速度？

2 个赞
23

在客户端，Discourse 不会为禁用的插件提供任何 JavaScript 资源，因此那里不会有任何影响。

在服务器端，对于正确实现的插件（这里的所有插件都属于此类），禁用插件时会绕过插件的自定义。所以是的，技术上来说，检查启用/禁用状态可能会有轻微的开销，但这应该是微不足道的。

我们在这里合并的插件是我们运行在 discourse.org 托管的所有 Discourse 实例上的插件。因此，它们都在大规模环境下经过了非常充分的测试。

15 个赞
24

明白了。感谢您的澄清！

2 个赞
25

在发布前不久一次性做这么多，有什么原因吗？对于那些利用业余时间进行翻译的人来说，两周内增加 3,000 个字符串是一个很大的工作量。而且，即使在之前已经翻译过插件的语言中，所有 3,000 个文本也需要重新校对。偶尔 300 个可能比 3,000 个更容易处理。

6 个赞
26

对于已运行一个或多个这些插件的自托管社区，当插件从 app.yml 中移除并合并到核心时，是否会丢失配置数据？

我已经按照我想要的方式设置了 AI 插件；如果我需要重新配置它（或者至少写下配置选项以便重新添加它们），我现在知道会很好。:+1:

6 个赞
27

我们一直试图通过利用 crowdin 中的翻译记忆库，让翻译人员尽可能顺利地进行翻译，这样就无需从头开始重新翻译。但即便如此，我同意，需要校对的内容确实很多。

我想知道我们是否还能在此处自动化更多内容，例如，也许我们可以“自动批准”来自这些插件的任何字符串，而不是要求校对 :eyes:

所有配置/数据都将得到维护。

10 个赞
28

UI 中提示重建但注定会失败的消息感觉非常不雅。

有没有办法至少为运行最低 Docker 管理员版本的站点标记此主题？

2 个赞
29

不过，这个元主题并不是你真正想看到的。

难点在于知道应该从你的 app.yml 中删除哪些插件，哪些不应该删除。