我认为他们建议的是，如果一个已经包含在核心中的插件在 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 插件添加了一个简单、可选的用户界面，用于从“最新”信息流中隐藏选定的类别。它通过以下位置的单个下拉菜单集成：
管理 → 设置 → 类别
“从主页隐藏的类别”
这似乎是一个非常自然的核心设置——尤其因为：
• 它是官方的并且积极维护
• 除非管理员选择启用，否则它默认保持禁用状态
• 许多社区（包括我的社区）依赖“最新”作为主要的登陆视图，并希望对其显示的内容进行更精细地控制
团队是否会考虑捆绑此插件（仍默认禁用），以便管理员无需安装任何额外内容即可使用此切换？
感谢您的考虑——这似乎是一个小的用户界面偏好，许多网站都可以从中受益，无需额外安装即可使用。
3 个赞
此主题已在 2 天后自动关闭。不再允许回复。
我不确定这是否是故意的，但想报告一下：
我们使用的是过时的稳定版 v3.5.4，并且正在使用 cakeday 插件。然而，（相同 Discourse 版本的）重建停止工作了，因为 cakeday 已合并到核心中。因此，我在 yml 文件中禁用了该插件……嗯，它消失了。现在它又可以构建了，但由于管理界面没有显示已安装该功能的迹象，我们再也没有“生日”功能了。
我猜这是因为我们使用的是过时的稳定版本，但对于相同版本的 Discourse 重建来说，这仍然是一个意外的结果。
cakeday 插件未包含在 3.5.4 中，所以这就是您看不到它的原因。
您确定是这个原因导致它们开始失败的吗？如果您看到了类似以下内容：
提示：插件 ‘$plugin’ 现已与 Discourse 打包在一起，不应包含在您的容器配置中
那么我恐怕这会显示在任何失败的重建上，只要 cakeday 插件包含在配置文件中。这是我们警告人们该问题的最有效方法，但这可能会让运行旧核心版本的人感到困惑。
所以，如果您需要 cakeday 插件，我想您应该能够将其重新添加到您的 app.yml 文件中并重建。我怀疑失败是由其他原因引起的，而您现在已经解决了。
顺便说一句：我强烈建议您升级到受支持的版本。3.5 不再接收安全更新，并且可能容易受到攻击。
看起来是这样：
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
将插件重新添加到 app.yml 会导致上述错误。立即将其删除后，构建就能再次工作。这个插件似乎是唯一的问题。
我意识到我们使用的是过时的版本，并且升级已在路线图上。只是想指出，尽管我们没有更改正在运行的版本，但 3.5.4（带有插件）的构建以前可以正常工作，但现在没有插件就无法构建了，而且我们似乎无法通过插件或核心来恢复插件功能。
1 个赞
很有趣！我想知道这是否是因为我们的 Docker 镜像现在包含了 discourse-cakeday，然后在核心“降级”到 3.5 时，它会留下一个空目录。
如果您在 git clone https://.../discourse-cakeday 这一行之前添加 rm -rf discourse-cakeday，那么应该可以清理它。所以它看起来会像这样：
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- rm -rf discourse-cakeday
- git clone https://github.com/discourse/discourse-cakeday
4 个赞
是的，解决了。它又可以工作了——谢谢！
2 个赞
抱歉将话题稍微偏离了，但我觉得没有更合适的主题，而且这与之前的问题有些关系。
自上次消息以来，我认为 discourse/docker_manager 上又进行了进一步的更改，导致旧版本构建出现更多问题。在今天重新构建后，Discourse 的整个管理界面停止工作，并出现类似以下的错误：
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
我通过在 yml 中使用以下命令修复了构建：
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
不确定是哪个提交导致了问题，但这足以让它恢复正常工作。
我知道，我知道，我必须升级（我是认真的）。但是，可能还有其他像我们一样的人，因为这样或那样的原因，被困在旧版本上比计划的时间更长，而没有更改版本就导致旧版本构建中断是有点出乎意料的。
无论如何，我已经找到了一个权宜之计，直到我们升级，所以只是分享这个，以防对处于相同情况的其他人有用。
1 个赞
您正在运行哪个版本的 Discourse 核心？还是 3.5？
是的，3.5.4。希望很快就能升级。
1 个赞