我没有收到此提示。但我遵循了错误日志并删除了这些行。现在正在重新构建。
编辑：除了引入故障和 20 分钟离线之外，如果在升级前不删除这些插件行；我们是否真的需要预装插件的额外臃肿？
我对大局感到好奇。默认捆绑这些插件的理由是什么？
就我个人而言，这感觉有点像 Windows、移动操作系统和一些软件在默认情况下添加更多预装组件（臃肿）的方向，而我们中的许多人通常会尽量避免这种情况。
我敢肯定，在实施此更改之前，可能已经与社区进行了讨论。如果是这样，则无需重复回复，只需提供相关讨论或公告的链接，以便我阅读有关此决定是如何以及为何做出的。
谢谢大家！
既然是在这个话题下，你可能已经读过了：
嗯，来自OP的第一章：
捆绑更多常用插件也允许更多网站利用无需自行编译 JS，从而缩短构建时间和降低资源成本。
我已自行托管，默认安装
所以我还没有点击升级按钮，因为我使用了一些现在已捆绑的插件。我不害怕，几个月前我经历过数据库升级。
是最好从 op 中的列表更新我的 app.yml（当然是先备份），还是会在 UI 中收到有意义的错误消息，告知我需要删除哪些插件并停止更新？
您可以使用此 grep 来列出在重新构建之前必须从 app.yml 中删除的插件。
我使用此方法重建了所有 Discourse，在这次插件更新后没有出现任何故障。
这在主题标题中已经有所回答。受欢迎通常意味着普遍安装和使用。为“自我极客”（Self Hipsters）捆绑它们意味着您无需花费时间进行安装。许多插件和 TC 最终与核心程序合并。
让这些插件作为插件开始开发的好处是，有开发时间来测试消费者的偏好并充分完善它们。
当然，会有各种各样的社区不使用任何新捆绑到核心中的插件。但更大的指标可能表明这些通常是在设置后安装的。然后，当然，他们还有来自其付费托管的插件使用情况和基础套餐中未使用的插件的指标。
在重建之前，我错过了 2 个插件。然而，错误日志的改进要好得多，可以轻松识别出这一点，而以前则需要向上滚动并识别问题。
我认为 David 提到的提示要么是重建错误，要么可能是在您的插件页面上进行 Web 更新。
别担心，提问前不总是能轻易看到答案。
我自己更新了 app.yml。
使用注释，我将我的内容按插件提供商进行了组织，以便于排序。话虽如此，这仍然有点麻烦。我认为再往上几帖有人发布了一种在重建之前进行检查的方法。
谢谢你，Dan，我会编辑 app.yml
说实话，因为这是公告帖，所以我来到这里并发表了评论，因为更新失败了，我没有收到需要先进行编辑的通知。然后，一旦解决了这个问题，我就编辑了帖子。但如果这是唯一的公开讨论，那就谢谢了。
我能理解优点，但肯定也有缺点。所以我觉得不是每个 Discourse 论坛所有者都会热衷于插件。所以提供一个选项会更好。也许在更新期间会有一个提示，或者在管理员区域有一个设置或通知，提醒您在下次更新之前设置您的偏好。
是否有按日期列出已合并插件的页面？我不喜欢通过 Web 管理员升级，以免失败。我使用的是 3.5.0.beta9-dev (04dbc622ab)。
也许我错过了安装了更新的日期/版本页面。谢谢。
您可以在 Discourse 仓库的 plugins 目录中查找。
据我所见，似乎从这里开始：
其中很大一部分也在这个页面上：
这是如何工作的？在我看来，有些是默认启用的。
那么您已经拥有了插件。
想法可能是它们是最受欢迎的插件，而且大多数人已经在（像你自己一样）使用它们的某种组合。这并不是真正的“臃肿软件”，因为它们几乎没有占用任何资源，而且你不需要使用它们中的任何一个。这与在 Windows 上安装 20 个我不想要的程序大不相同，这些是开关（大多数人看不到，而你作为管理员会在你已经不使用/不更改的 300 个其他东西的列表中看到它们），而不是不断出现/占用实际空间/默认设置为执行某些操作的东西。默认安装一个我不想要的记事本程序意味着我将拥有两个。安装一个我不想要的插件意味着它只是面板中的一个选项
拥有开关也比在第三方论坛（或无休止的 GitHub）中搜索你甚至不知道存在的东西要容易得多。实际上，这是我第一次意识到其中的一些插件。
我终于有时间更新到 3.5.0.beta9-dev (df03ef6d05)
我是自托管的标准安装
我编辑了我的 app.yml 以删除插件行（根据 Dan 在上面的建议），然后继续开始更新过程。我必须像往常一样先更新 docker manager，一切正常。一旦 docker manager 更新完成，我看到一个对我来说是新的消息。
我之前做过重建，所以我知道该怎么做，而且 putty 仍然打开着我的服务器，所以这并不麻烦，但我有点惊讶我不能使用 UI 来进行更新。我只是发布这个信息，提醒像我一样的其他自托管新手。除此之外，更新进行得很顺利，一切运行正常。感谢团队和社区。
对于已解决、主题投票和模板，您说得对，插件本身已启用。但这些插件在特定类别启用相关功能之前不会执行任何操作。
我希望你们能更关注维护兼容性，而不是每次更新网站时都让我们浪费半天时间。稍微整理一下代码不值得破坏人们的网站并浪费他们的时间。
坦白说，我开始寻找 Discourse 的替代品了，因为我厌倦了我的整个网站每隔几个月就崩溃一次，而且我不得不花时间去弄清楚如何修复它，而这一切都不是我的专长。
很遗憾听到您感到沮丧——尽管我不确定您在这里遇到了哪些关于捆绑插件的具体问题？
我们努力使升级尽可能轻松/直接，但像这样的大变动有时不可避免地会造成一些摩擦。在这种情况下，我们添加了特定的错误输出，说明如何修改您网站的配置，使其尽可能简单地进行修复。
我认为存在的一个问题是 Discourse_docker 在知道何时需要命令行重建方面做得不好。这使得通过点击管理面板上的升级来破坏你的站点变得很容易。（至少我认为我看到人们在抱怨这个问题）
我认为我以前看到过声称做了这些事情的提交，而且我认为我现在看不到那么多。我自己（几乎）不使用 discourse_docker，所以我没有密切关注。
如果该用户运行了重建而不是通过用户体验进行升级，他们本可以只运行
./launcher start app
并在方便的时候再处理升级。