在我早期自行托管 Discourse 时，曾遇到过“插件重建失败”的问题，因此我理解将已知良好版本捆绑到核心并可能提供更丰富功能选择的愿望。
以客户为中心的组织可以就核心插件方向或至少是时机进行民意调查。也许我错过了。作为我客户（即最终用户）的 IT 工具提供商，他们试图通过 IT 完成实际工作，我见过许多产品因过度复杂化而最终被取代。现在我们将有自行托管者“rm -fr”掉他们不需要的插件。我理解这一点，并且可能会加入那个俱乐部。根据我的经验，额外的代码会增加集成复杂性、配置错误的风险以及攻击面。但迟早，移除应用程序开发人员假定会存在的东西也会破坏某些东西。
我更希望 Discourse 的高手们能致力于开发一种健壮、维护良好、可脚本化的方法来启用云存储图像，包括 CDN 集成。与此相比，SMTP 电子邮件集成是微不足道的，而这已经因为 MailGun 等公司的更改而中断，给自行托管的站点带来了麻烦。
确实，我强烈建议不要对这些插件使用 rm -rf。正如你所说，未来存在意外的相互依赖风险。但此外，你将在核心 git 存储库中创建一个差异，这意味着通过 docker_manager 进行的 UI 更新几乎肯定会失败。
当然，将这些插件保留在其默认的“禁用”状态是完全支持的，并且可以确保它们不会产生任何可衡量的性能影响。
我们需要一种方法来排除插件，即使它们位于插件目录中，也不会被找到。
对于自行托管者或像我一样为客户提供托管服务的用户，这里有一个简单的 grep 命令，它将列出任何新的捆绑插件是否已存在于您的 containers/app.yml 中。
grep -E 'git clone .*(discourse-(adplugin|affiliate|ai|apple-auth|assign|calendar|chat-integration|data-explorer|gamification|github|graphviz|hcaptcha|login-with-amazon|lti|math|microsoft-auth|oauth2-basic|openid-connect|patreon|policy|post-voting|reactions|rss-polling|solved|subscriptions|templates|topic-voting|user-notes|zendesk-plugin|cakeday))' containers/app.yml
需要以 root 身份运行，它将输出在重建之前需要从 app.yml 的插件部分手动删除的任何行。
@pacharanero 感谢您整理这些内容！
可以考虑将其更改为引用 containers.*.yml，这样也有助于那些进行了标准双容器安装的人，因为他们会将它们放在 web-only 中？毕竟，您确实不希望它们出现在任何容器定义中。
@david 您是否考虑将其添加到首个帖子中，并在集成 cakeday 后进行维护？
感谢 ChatGPT，它根据以下提示一次性准确地完成了这项工作：
请抓取此帖子中提到的每个插件的 GitHub URL
https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3将它们编译成一个列表，并创建一个 Unix 命令，用于告诉我这些插件中是否有任何一个已在 Discourse 的 containers/app.yml 中被“git clone”提及。
表面上看，对我来说，这听起来确实是将来可以考虑做的一件合理的事情——有一种更声明式的方法来定义在启动时加载或不加载哪些插件，即使源文件仍然存在于磁盘上。
话虽如此，我不知道这样做的可行性或工作量有多大。
这当然是可能的。但这会增加复杂性——又一个需要支持/维护的东西。而且它只在单租户环境中有用（即，在共享托管环境中无效，因为不同的租户想要不同的插件）。
如果非要说的话，我认为花时间改进“已禁用”插件的用户体验和性能会更有益（自从这次大规模合并到核心以来，我们已经开始这样做了）。
我还未尝试移除插件，因为我觉得这会影响我向 Meta 提交 Bug 报告的质量，甚至会影响共享主机安装的尝试。
哎呀，这次更新太艰难了。一开始，要在混乱的重建日志中找出问题并非易事。找到了，我两次忽略了从配置中移除另一个插件，因此第三次重建尝试终于通过了那部分。如果一开始就能检查并警告配置需要调整，那将非常有帮助。discourse-doctor 会检查配置中的插件（虽然很简单，但可以作为起点），所以可以以此为基础。现在 3 周后可能太晚了，不管了……
但这还不是全部，我们还遇到了 db:migrate 错误。我重试了两次，然后运行了 discourse-doctor，它也进行了重建，并且奇怪地成功了。我查看了它的代码，它什么也没做，并且调用重建的方式与我们完全相同。因此，看起来 db:migrate 是因为某种原因在第三次尝试时才成功的？我通读了帖子，其中提到添加的大量插件会增加依赖项，这些依赖项可能与之前使用的冲突/更旧。幸运的是，我们不需要像其他人那样添加手动插件移除步骤、依赖项调整或数据库更改。db:migrate 多次运行最终会成功，这是可以预期的吗？我只能希望没有东西坏掉……
它之前就被安装了，我们只是从 UI 中省略了它，就像之前捆绑的其他插件一样。我们的 UI 得到了改进，可以正确地展示所有已有的东西。（我们遗漏了很多东西，包括通过 CSS 隐藏的聊天功能）
我已经在很短的时间内观察到内部开发团队的速度有所提高。这正在带来一个更稳定的产品，我对此非常满意。
没有回退的计划。你需要适应新的世界。
3 个帖子被拆分到一个新主题：帮助我调试失败的迁移
在我看来，如果某个东西因为没有安装插件而损坏，那么这本身就是一个 Bug。核心不应该依赖插件。插件本身应该在其各自的页面上清楚地列出其要求。
但是，是的，这只会让自托管版本在未来更加不稳定，因为自托管者将会在这些问题中跌跌撞撞。介于此和分叉的帖子之间，我真的不觉得团队会优先考虑自托管的稳定性。
我们事先没有考虑到这一点，所以可能遗漏了一些批准。但我们设法将其中很大一部分从 Crowdin 上的插件项目转移到了核心。下次我们会做得更好，因为我们现在有了在项目之间转移批准的工具。
没有，我们事先没有检查，但我事后检查了。没有一个插件在 Crowdin 上有未回复的评论。我们有一个内部工具，可以存储发布在我们 Crowdin 插件上的所有评论。我们甚至可以用它来重新发布 Crowdin 上丢失的评论，例如当 Crowdin 因源字符串更新而删除评论时。这只是还没有被优先实现。
这里再多一个选项会很好：
“已启用插件”
这样可以避免“已安装插件”中最初出现的大量列表。
另外，为了方便实现这一点：
所以：
https://example.com/admin/plugins?filter=enabled
同意。也许有一个选项可以列出已启用核心安装的插件，而不是只显示所有插件。增加过滤选项绝对更好。
我同意这种观点。恕我直言，真正的问题在于将它们保留为插件。
一旦合并，它应该被移到一个品牌化的名称下，比如“核心功能”，因为插件被视为可以安装的可选组件，而不是主程序的一部分。因此，我认为将它们列为插件，但意图却不是要卸载它们，这是不恰当的。
这类似于 TC 被合并到核心中，比如“个人气泡”没有列在主题组件中。当然，在这种特定情况下，你无法禁用前者 TC。如果你想恢复到以前的样子，你需要创建一个 TC 来撤销更改 
我绝对同意需要额外的筛选选项。也应该为禁用的插件提供一个。
然而，经过更多思考和阅读更多帖子后。如果插件与核心合并。它们可能真的不应该再被称为插件，也不应该列在插件中。但也许可以称之为“核心功能”或“可选功能”。因为这些实际上不再可以被卸载了。
没有理由说明精心设计的论坛软件会需要广告代码才能运行。
如果 Discourse 决定内置反功能，它只会迫使人们要么分叉 Discourse，要么迁移到其他东西。我们这些不喜欢大型科技/广告的人对此非常反感。无论多么用力地推动，Discourse 都不会强迫我们这样做。（Ubuntu 曾试图这样做，现在我星标最多的仓库就是移除广告的东西；））
不太明白你的意思。如果你的意思是广告代码是指那些被合并到核心产品中的插件，而不是可选的附加组件/安装。如果我们回顾一下，你会发现各种“广告代码”被合并到了核心中。
我从开发团队的角度来看，他们的许多插件可能最初是为了在集成到核心程序之前进行更灵活的测试而开发的。
我理解，就像任何软件一样，通常会有人们可能不会使用并选择禁用的功能，并且需要找到卸载功能的方法。
虽然我承认最近有很多合并的插件我可能不会使用。但拥有一个简单的禁用选项并过滤掉它们对所有人来说都是一件好事。
我理解，正如团队所说，部分目的是通过附加组件使自托管更加容易。
现在，依我看，管理界面应该像以前一样更具可定制性。这也有助于人们从另一个平台迁移过来，因为他们可以加载一个与他们正在使用的平台布局相似的管理界面。就像 Linux 通过模仿其他操作系统来做到这一点一样。但那是另一个话题。
我理解有人觉得 Discourse 可能开始走向臃肿软件。Reactors 证明了 Windows NT 可以多么精简。
