在升级页面，等待所有插件检查更新总是很耗时，而且最终发现 docker_manager 需要优先升级。是否有办法让升级系统在检查任何新版本之前，先检查 docker_manager 是否需要更新？这样可以节省大量 HTTP 请求，也为那些在升级上花费不必要时间的管理员节省时间。
12 个赞
这对我来说是个好主意，如果有人愿意来做，我相信这会被标记为 pr-welcome 
7 个赞
好主意。再也不用先往下滚动才能查看了。
5 个赞
我决定尝试一下。PR 在这里：UX: Always show the docker_manager plugin second in the list by davidtaylorhq · Pull Request #100 · discourse/docker_manager · GitHub
这将始终让 docker_manager 排在列表中第二位，紧随 discourse 之后：
编辑：已合并 
14 个赞
感谢 @david！如果 docker_manager 不是最新版本，它是否会跳过对其他插件的检查？
3 个赞
不，它并不会跳过这些操作，只是意味着 docker_manager 会优先执行。管理员可以立即点击 docker_manager 的更新按钮，即使其他插件仍在加载中。
我认为，即使无法立即安装，查看其他插件是否有可用更新仍然很有意义？
5 个赞
通常，当你看到新的 docker_manager 版本发布时，是因为你的管理员通知中已宣布有新的 Discourse 版本，因此你很可能需要执行以下步骤：1. 升级 docker_manager，然后 2. 升级所有组件，这种情况在 80% 到 90% 的时候都会发生。
当你想要检查单个插件时，无论如何都需要向下滚动。我主要考虑的是资源浪费问题。经过几年的升级，跨越成千上万个实例，这将节省大量资源。
我认为一个折中的方案是在点击 docker_manager 升级按钮时终止检查请求。但我认为，当此插件已过期时 simply 不 进行检查才是更合理的做法——我没有统计数据，也许你有。
4 个赞
在我们的托管服务中，我们不使用 docker_manager，所以很遗憾没有统计数据。
不过，“检查更新”是一项成本极低的操作。在底层，docker_manager 会对每个插件执行 git remote update。它仅拉取自上次检查以来的变更，因此数据传输量应该非常小。
5 个赞
此主题在 6 天后自动关闭。不再允许新的回复。