您好，当我尝试连接到管理界面时，屏幕一片空白。我无法进行更新，即使我是管理员。
我该怎么办？
感谢您的帮助。
Muriel
1 个赞
您可以尝试安全模式。您也可以尝试命令行升级。
3 个赞
更新: 我进行了正确的引导、销毁、启动，使用了 2 容器设置，现在报告的版本号已更新，并且 Admin UI 再次渲染。
其余帖子保留以供参考。
我遇到了一个可能类似的问题。Admin 界面加载了，但只显示顶部的选项卡，主内容区域为空：
浏览器控制台日志
查看浏览器控制台日志，我看到类似以下的错误：
[Error] Error: VM BUG: Target must be set before attempting to jump
vendor.xxxxx-xxxx.js
Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
错误堆栈
[Error] Error: VM BUG: Target must be set before attempting to jump
b (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:131956)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:69428)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:156653)
_runExpiredTimers (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:160801)
[Error] Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1310)
h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1311)
(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:3065)
h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1375)
requireModule (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:599)
_extractDefaultExport (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:269780)
resolveOther (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266326)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266888)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262092)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262185)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262275)
c (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:260192)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:258815)
getRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:56849)
fetchRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:267571)
_getQPMeta (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63399)
_hydrateUnsuppliedQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:64113)
_prepareQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63271)
normaliseQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38898)
_generateURL (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38990)
eA (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:202925)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49065)
X (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:140358)
T (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49044)
eM (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:80191)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:79868)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:70930)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:65312)
evaluateSyscall (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111047)
evaluateInner (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110609)
evaluateOuter (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110528)
next (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121496)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121359)
handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:112232)
handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:114799)
throw (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111583)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:68993)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:155980)
升级过程 (2 容器)
我最初在尝试通过 Discourse Admin UI 完成升级时遇到了这个问题，当时显示我需要先更新 Docker Manager。
更新 Docker Manager 后，我遇到了这个问题，于是 SSH 登录到服务器并对手动（2 容器）更新了 web_only：
cd /var/discourse
git pull
./launcher bootstrap web_only
./launcher stop web_only && ./launcher start web_only
^^^^
⚠️ This is wrong! Use destroy per below. ⚠️
奇怪的是，/about.json 路径仍然显示我运行的是 3.4.0.beta4-dev，这正是我认为我开始的版本，因为原始邮件是关于从 3.4.0.beta4-dev 升级到 3.5.0.beta1 的。
我仔细检查了 git log，似乎至少 discourse_docker 在撰写本文时已更新到最新提交 3715498fc188d60c0b579443383c4e973cf26f59。
安全模式有效
我之前不知道安全模式，但如果我禁用所有客户端插件，问题似乎就不会发生。
仅禁用非官方客户端插件自定义不会解决问题，因为我尝试了每种组合来缩小范围。
| 选项 | 结果 |
|---|---|
no_unofficial_plugins |
 |
no_plugins |
 |
no_themes |
|
禁用 docker_manager 无效
我尝试在 hooks/after_code 下注释掉 docker_manager 插件，然后重新构建 web_only 容器并停止&启动，但上面提到的客户端错误消息仍然存在。
这确实引入了另一个错误消息，即访问 this.class.create 的 Admin 页面时出现“不是函数”，但这可能是因为在此测试中底层 docker_manager 插件被禁用了：
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
at loader.js:247:1
at h (loader.js:258:1)
at u.findDeps (loader.js:168:1)
at h (loader.js:262:1)
at requireModule (loader.js:24:1)
at f.get (composer.js:874:1)
at push.98673._extractDefaultExport (composer.js:874:1)
at push.98673.resolveOther (composer.js:874:1)
at push.98673.resolve (composer.js:874:1)
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
index.js:78 Uncaught TypeError: this.class.create is not a function
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
同样，使用安全模式和 no_plugins 可以暂时解决问题。
我凭记忆输入了用于 2 容器最小停机时间更新的命令，看来我的记忆不可靠！
在使用正确的命令销毁并在引导后启动新容器后，我看到版本已更新，并且管理员界面按预期工作。
您升级了数据容器吗？您应该这样做，但首先，请参阅PostgreSQL 15 更新。或者，如果您真的讨厌阅读，只需运行 ./laumcher rebuild data 两次即可。然后您需要销毁并启动 Web 容器（否则它会寻找您已销毁的旧数据容器）。
还没有，但谢谢你的关心！
我已经考虑设置一台新的、更强大的服务器，所以我只是在研究是否可以从 Discourse 3.5 + PG13 进行备份，然后在另一台主机上恢复到 Discourse 3.5 + PG15。
我不喜欢长时间停机，过去我曾暂时将社区设置为只读模式，并在服务器实例之间进行备份/恢复，这样几乎没有停机时间（当然，除了只读期间）。所以我想我会研究/测试一下，看看它是否适用于不同的 PG 版本。
否则，我将不得不硬着头皮，在服务器迁移之前先进行 PG15 升级。 
1 个赞
它确实可以。也许是时候升级你的操作系统了。只需启动一个新服务器并恢复你的备份。
2 个赞
我遇到了完全相同的问题。感谢您的帮助。我的网站管理员 Benjamin 会读到您的回复。
Muriel
这就是发生在我身上的事情。启动新服务器并从备份恢复是唯一的选择。 他直截了当。 不要浪费时间调试。 这条建议可以让你很快解决问题。
我最终完成了备份和恢复，并且一切按预期进行。
供以后参考，以防其他人遇到类似问题……
起初我遇到了一些问题，因为恢复过程似乎在内部调用 uploads:migrate_to_s3，并且它卡住了。
[2025-02-26 00:24:16] Migrating the database...
[2025-02-26 00:24:24]
[2025-02-26 00:24:24] Reconnecting to the database...
[2025-02-26 00:24:24] Reloading site settings...
[2025-02-26 00:24:24] Disabling outgoing emails for non-staff users...
[2025-02-26 00:24:24] Disabling readonly mode...
[2025-02-26 00:24:24] Clearing category cache...
[2025-02-26 00:24:24] Reloading translations...
[2025-02-26 00:24:24] Remapping uploads...
[2025-02-26 00:24:24] Restoring uploads, this may take a while...
[2025-02-26 00:25:09] EXCEPTION: 12 of 12208 uploads are not migrated to S3. S3 migration failed for db 'default'.
[2025-02-26 00:25:09] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:73:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:383:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:354:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2025-02-26 00:25:09] Trying to rollback...
[2025-02-26 00:25:09] Rolling back...
[2025-02-26 00:25:10] Cleaning stuff up...
我最终在数据容器中运行了一些 SQL 查询，看看是否能找出问题所在。
./launcher enter data
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%s3%';
这只返回了一些 Discourse 的标准内置项，所以我尝试了反向查询：
SELECT url from uploads where url LIKE '%s3%' limit 10;
这给了我很多匹配项，格式如下：
//{my-bucket-name}.s3.dualstack.us-east-2.amazonaws.com/original/2X/5/{image-id}.jpeg
然后我尝试了一个查询，找出不匹配 s3.dualstack 主机的项目，我发现有 12 个旧条目使用了略有不同的格式（与之前恢复日志失败的失败数量相匹配）。
//{my-bucket-name}.s3-us-east-2.amazonaws.com/{file-path}.jpeg
当我检查实际存储桶中这些文件的存在性时，它们并不存在，所以我最终使用类似以下命令删除了它们：
DELETE FROM uploads where url LIKE '%{my-bucket-name}.s3-us-east-2.amazonaws.com%';
在那之后，备份和恢复按预期工作！
附注：别忘了在恢复备份后重新启用电子邮件！
/admin/site_settings/category/all_results?filter=disable_email
4 个赞
2 篇帖子已拆分为新主题：更新已有 10 年历史的网站时遇到问题