我认为他们建议的是，如果一个已经包含在核心中的插件在 app.yaml 中被列出，那么它将被忽略。并附带一个通知，说明在 app.yaml 中包含它是多余的，并且所有者可以删除它。
我也觉得只要我的 app.yaml 中列出了任何插件，我就有失败更新的风险，这有点令人恼火。所以每次更新时，我都需要仔细检查是否我的某个插件已被添加到核心中。
3 个赞
为什么不直接提供一个脚本来为系统管理员处理呢？
我自己会按团队或作者来组织插件，让生活更轻松一些，这样我就知道哪些插件是官方的等等。但如果目的是让 discourse 更用户友好，那需要在团队层面进行。
这与您在用户因 Postreq（还是？）升级失败导致升级失败时提供建议的情况并没有太大区别。
对于插件，这正是 Procourse Installer 的概念，它是一个很好的想法，可以在不使用命令行的情况下简化插件的安装和卸载。
诚然，我明白在出现问题时可能需要更多的润色。但这可以通过日志文件或在需要时从命令行进行简单的回退来轻松实现。我很感激这可能会使自托管比付费计划更具吸引力。但是，付费计划仍然有足够的优点可以支持。
这种类型的插件管理器也可以被定制或分支，以便托管计划的用户可以在其托管层内安装插件，因为某些插件可能在特定计划中不需要。
1 个赞
确实，我很久以前错过了一篇关于聊天捆绑的帖子，并试图安装它。我认为插件上的标签没有更新。当然，它导致网站崩溃，因为它不喜欢在理论上可以简单地忽略该条目并完成重建，告知可以将其删除，因为它是不必要的，但却试图安装该插件。
1 个赞
好的，收到反馈！ 
我认为现在可以关闭此主题了——我会设置一个计时器，以便同事们有机会回复（如果他们想的话）。
whos-online 是否会进入核心？
随着最近将更多官方插件捆绑到核心的举措，我想知道“在线用户”插件是否正在被考虑纳入其中。
我注意到它在官方托管计划中可用（计入插件配额），所以我很好奇这是否表明正在朝着更广泛的采用迈进。
我完全理解，如果性能限制或理念契合意味着它应该默认保持关闭状态，除非在 app.yml 中另有规定。
谢谢！
2 个赞
我们目前不打算将更多插件移入核心。Cakeday 是最后一个，由于它之前默认启用的方式存在一些复杂性，因此不得不单独进行。
我完全理解您对这个过程的沮丧——它肯定不像我希望的那样顺利。为了提供一些背景信息：根本问题在于 app.yml 文件不是 Discourse 的配置文件。它们是 pups 配置文件，插件安装行只是 shell 命令。
将 Discourse 特定的逻辑引入 pups，并让它忽略某些 shell 命令，实际上不是一个选项。此工具不仅用于 Discourse。此外，我怀疑许多人会不满意我们在他们不知情的情况下更改引导过程中运行的 shell 命令。
因此，我们找到了一个可行的、最简洁的解决方案：强制进行 CLI 重建，然后显示一条消息，要求用户从其配置中删除受影响的行。
5 个赞
有趣的帖子，David！
我在“Who’s Online”插件主题的 OP 中注意到：
在安装此插件之前请仔细考虑
我认为将“安装”改为“启用”可能更合适——如果从技术上讲是正确的。
目前的措辞可能会给人一种印象，即拥有额外的捆绑插件存在 哲学或性能 问题——而实际上只在于它们是否被 启用。由于一个之前未启用的新核心插件在重建后默认处于禁用状态，风险不在于将其与核心一起安装，而在于启用它。
这并非必然如此，请参阅 Disabled plugins still causing performance impact
现在，该特定问题（对于捆绑插件而言）已经（在很大程度上）得到解决，但对于其他插件而言，这可能仍然会偶尔发生。
2 个赞
discourse-categories-suppressed 插件添加了一个简单、可选的用户界面，用于从“最新”信息流中隐藏选定的类别。它通过以下位置的单个下拉菜单集成：
管理 → 设置 → 类别
“从主页隐藏的类别”
这似乎是一个非常自然的核心设置——尤其因为：
• 它是官方的并且积极维护
• 除非管理员选择启用，否则它默认保持禁用状态
• 许多社区（包括我的社区）依赖“最新”作为主要的登陆视图，并希望对其显示的内容进行更精细地控制
团队是否会考虑捆绑此插件（仍默认禁用），以便管理员无需安装任何额外内容即可使用此切换？
感谢您的考虑——这似乎是一个小的用户界面偏好，许多网站都可以从中受益，无需额外安装即可使用。
2 个赞
此主题已在 2 天后自动关闭。不再允许回复。