恢复后，所有内部链接都使用了测试 URL 域名，导致所有链接失效。我不确定为什么它没有采用正确的站点 URL。除了进入代码/数据库进行大规模查找和替换之外，还有其他方法可以解决这个问题吗？
我在想是否可以进行一次“重新恢复”？
您需要进入数据库执行批量查找/替换。
有一个工具可以做到这一点：
RAILS_ENV=production discourse remap //old.domain //new.domain
4 个赞
您可以按描述进行修复，但这不应该发生。
您是使用 /admin/backups 进行备份和还原的吗？
两个系统的主机名都设置正确吗？
3 个赞
谢谢。看起来很简单。我进入了应用程序并运行了它，但似乎没有改变帖子中 URL 的实例。
这是重映射：
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
它在“default”数据库上运行并完成，花费了几分钟，然后报告“完成”，没有错误。
我查看了一些精选帖子，但帖子上的 URL 链接似乎没有任何变化。
我重建了一些帖子进行测试，在这些帖子中我看到了 dev.domain.com 而不是实时链接中的 domain.com，但它们保持不变。
然后我运行了相同的命令，但省略了 https:// 并收到此错误：
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
我猜数据库中有一个聊天消息导致它停止，但不确定为什么。我想我需要以某种方式在数据库中看到它，正如你所知，我通常管理 Discourse 的方式从来不是通过数据库。
最后，我重新运行了原始的重映射，花费了几分钟并报告“完成”，没有错误：
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
也许我需要重新烘焙帖子才能看到效果？
我以为帖子重建是逐个帖子执行的相同操作。
或者重建应用程序？
应该是：
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
使用 // 的原因是它能匹配 http://、https:// 和无协议的 URL，但不会匹配电子邮件地址的域名。
你这样做之后会发生什么？
2 个赞
好的，又出现同样的错误了：
正在重新映射表...
错误：错误：重复的键值违反了唯一约束“index_post_hotlinked_media_on_post_id_and_url_md5”
详细信息：键 (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) 已存在。
由于上述错误，重新映射仅部分应用。请再次运行脚本。
所以至少我使用了正确的写入命令，情况在好转！
还有其他想法吗？
除了这个 Rails 重新映射僵局之外，我想也许如果我备份数据库并再次恢复它，它可能会在恢复过程中正确地重新映射 Link-urls？
我仍然遇到的错误似乎与此处需要修复的停止错误重复或非常相似：
Error: ERROR: duplicate key value violates unique constraint \"index_post_hotlinked_media_on_post_id_and_url_md5\"
DETAIL: Key (post_id, md5(url::text))=...
在尝试重新映射时：
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
也许 @david 会有见解？
这看起来更像是一个 bug 吗？
那张表格中同时包含这两个域名的链接，所以当你尝试重新映射它们时，会得到重复的键。这不是一个错误。你是在尝试创建一个重复的键。
你可以删除该表格中具有顶级域名的项目。更好的做法是使用 www 代替顶级域名。
1 个赞
谢谢。我唯一担心的是这个 Discourse 部署也存在非 www / SSL 问题，例如 https://meta.discourse.org/t/how-to-add-ssl-to-non-www-domain/222869，但我会尝试你建议的重映射，如果它有效，它将迫使我解决非 www 问题！
重新映射的思考正如 @pfaffman 所建议的那样奏效，但实际上是解决方案的催化剂，而不是解决方案本身，它帮助我弄清楚我哪里做错了，它重新映射了我的眼睛！
如果我正确阅读了错误信息，即注意到了，我早就解决了这个问题，因为我会看到关键信息就在错误消息中。
我所要做的就是将停止错误标记的帖子编号 …/p/123456789 包含在 URL 中，以直接导航并手动修复每个帖子。
这发生在大多数情况下，在第二次重新映射运行时，将第一次重新映射的 www 转换为最初需要的非 www 根域 URL。
现在内部 URL 应该只包含根域链接。
这解决了 www SSL 重定向的一些问题，因为有很多旧的 www 内部链接。它不能解决用户在地址栏中输入 www 或在 WWW 本身上的链接回退问题，但它应该能处理所有内部生成的链接。在采取进一步措施解决此问题之前，等待观察它对 Google 索引的影响。
也许对开发者来说很有趣。
我发现了很多关于“重复键值违反唯一约束‘unique_post_links’”的停止错误，这些错误发生在帖子被移动并且 discourse 包含了*“继续阅读……“* 并带有热链接时，但如果拆分的帖子包含指向同一位置的引用块，则会停止重新映射。
这导致了大多数停止错误。
解决方案是删除重复的内部链接回退之一，或用代码括号括起来（并不总是有效），然后重新运行重新映射就会继续进行。
其他停止错误是由用户手动创建相同的帖子条件引起的，他们通过重新发布相同的链接回帖子，却不知道引用也链接回去了，也许是历史习惯、风格等因素在起作用，这表明许多用户仍然没有意识到 discourse 在链接方面做了多少工作来让生活更轻松，哦，真是讽刺！
重新映射后，我可以撤销编辑，但数量不多，不足以产生影响，而且仍然有一个正确的链接回帖子或引用的内部 discourse 源。
希望这能扭转 Google 将数万页取消索引到未索引的灰色 limbo 中的大部分情况。
一知半解是危险的！
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.