rails 命令或 rake 任务的重新烘焙不起作用,但重建 HTML 可以。为什么?

您好!

我正在尝试修复带有损坏图片的帖子,这些图片是导入的并且包含 BBcode。

图片在撰写器预览中显示,但最终的帖子内容包含损坏的图片:

在使用“重建 HTML”功能修复了一些帖子后,并在我的生产论坛上看到它已修复了帖子,我使用 rake 任务重新烘焙了所有帖子。

令我惊讶的是,带有损坏图片的帖子没有被修复。

因此,我在我的测试论坛(相同的备份;相同的数据)上通过 rails 命令和 rake 任务对特定帖子进行了实验性重新烘焙,以下是其行为:

  • 图片显示一秒钟,但帖子很快恢复到其初始状态,图片损坏。

但是,如果我使用“重建 HTML”功能,它会完美运行,并且图片不会恢复为损坏的图片。几分钟后,它们甚至会被正确上传到服务器。

那么,有人能解释一下这种现象吗?为什么 rails 或 rake 任务的重新烘焙会有这种行为,以及重建 HTML 和命令行重新烘焙之间有什么区别?

视频录像:

  1. 来自 rails 控制台:

  2. 来自 rake 任务:

我对此非常好奇(并且仍在尝试批量修复我所有帖子中的图片)。


一个我使用重建 HTML 的例子,显示该帖子的嵌入式图片已正确显示并自动上传到服务器(显然,它们的原始链接,指向 casimages,仍然存在,但这是预期的行为),几天前:Frensh Vw Bus CHERIZET 2019 SK - #13 par buggyderby - Vos sorties - VW Camper

4 个赞

我认为 rake 任务会标记它们进行重新烘焙,并触发缩略图重建。您是否已检查 sidekiq 以查看是否有内容排队?

3 个赞

编辑:

帖子上的 rake 重建任务会在 4 分钟后触发 PullHotLinkedImages,同时立即将已处理任务的数量增加一,但我没有在队列选项卡中看到任何添加的内容。

我手动对少数帖子进行了 HTML 重建,它们的图片已完美显示了几天(图片也已下载到我的服务器上)。

4 个赞

<s>抱歉,我不知道为什么它在管理员扳手和控制台中工作方式不同,但我找到了一个关于类似问题的帖子,他们通过使用 API 重新烘焙解决了问题:<s>

https://meta.discourse.org/t/some-linked-images-not-displaying-show-as-broken/142177/7

<s>不确定这是否有用,但我想分享一下。:slightly_smiling_face:<s>

编辑: 我应该再往前读一篇文章。显然那也不可靠。抱歉,我的错。虚惊一场。

3 个赞

10 个帖子已拆分为新主题:无法为某些域提取热链接图像

除了 Jay 曾隐约看出 rake/rails rebake 和 rebuild HTML 之间的区别外,还有其他人有其他想法吗?

如果能得到关于这些任务之间区别的官方回复就太好了 :slight_smile:

如果我们无法弄清楚,我将开始使用 API 来“重建 HTML”,处理我那包含潜在图片问题的 40000 篇帖子……并希望它能对我有效 :confused: :person_shrugging:

或者,如果使用 rails 有其他方法可以“重建 HTML”呢? :thinking:

Rebuild HTML:post.rebake!(invalidate_oneboxes: true, invalidate_broken_images: true)

Rake posts:rebakepost.rebake!(**opts),其中 opts 通常为空
对于 Oneboxes,您可以尝试任务 posts:refresh_oneboxes,对于损坏的图片,您可以尝试任务 posts:invalidate_broken_images。后者可能是您问题的解决方案。

8 个赞

经过对几个帖子的测试,它似乎效果很好!
我将在数千个帖子中进行测试,看看效果如何!非常感谢!

5 个赞

所以,我目前的状况是这样的:

在尝试对所有包含字符串 [img] 的 40000 篇帖子执行 post.rebake!(invalidate_broken_images: true) 后,很多图片的上传都成功了……但远非全部,尽管它们托管在同一个外部图片托管服务上。
例如,我有数千个“有效”的 casimages 链接(链接到有效的图片,并在编辑时的编辑器预览中显示图片),在帖子的已发布版本中却显示为损坏,尽管它们已通过我的脚本成功上传到服务器,但还有很多其他的图片根本没有上传,我不知道为什么。

Post.where('raw LIKE ?', '%[img]%').find_each do |p|
    p.rebake!(invalidate_broken_images: true)
end

我还有来自其他图片托管的图片链接,有些上传成功了,有些则没有。

我未能发现这些帖子和图片链接之间有任何区别。它们都包含有效的图片,而且它们使用相同的图片托管服务让我感到困惑。

我尝试了多次操作,结果却不一致,这与外部托管服务无关……有些图片被上传了,有些则没有。看起来像是随机的。

这让我想起了 @Amethi 遇到的问题:Some linked images not displaying/show as broken - #8 by Amethi


:information_source: 这里我只讨论 casimages,尽管我导入的论坛使用了各种其他图片托管服务。

所以,我曾想,也许 casimages 会暂时将我的 IP 列入黑名单,如果我尝试从他们的服务器检索过多图片。这可以解释为什么并非所有图片都上传成功,以及图片上传成功的随机性。
甚至出现过 Rebuild HTML 选项(起初只在第一次时)工作正常,图片显示出来而不是显示损坏的图片图标,尽管它们仍然托管在外部服务上,但当 Sidekiq 的“拉取外部图片”任务触发时,图片却损坏了。
使用 rebake!(invalidate_broken_images: true) 的 rail 脚本也是同样的情况。
:weary:

所以,我目前正在尝试一种更慢的方法,在每次执行 rail rebake! 命令之间等待 5 秒:

total = Post.where('lower(raw) LIKE ?', '%[img]https:%').count
i = 0
Post.where('raw LIKE ?', '%[img]https:%').find_each do |p|
    p.rebake!(invalidate_broken_images: true)
    print "#{i}/#{total}"
    print "\r"
    i += 1
    sleep(5)
end

我将在大约 60 小时后看看情况是否有所改善……

我想了解这个问题的根本原因,以及为什么“正常”的 rebake 无法将图片上传到服务器(如果我没有被 casimages 暂时列入黑名单)。

请注意,这次,casimages 服务器的证书似乎没问题:smile:

我也不太明白 invalidate_broken_images 到底做了什么。我对 Discourse 的代码不太熟悉。

我查看了代码中 invalidage_broken_images 的出现位置,看到了这些文件:

为什么它专门搜索 \u003cimg 字符串?我的帖子是从 phpBB 导入的,原始版本只包含 [img] bbCode,而不是 \u003cimg\u003e 标签;那么它怎么会对我的帖子产生影响(而且确实产生了影响,请看我之前的消息)? :thinking:

我也不太明白这两个方法之间的区别(?):

它似乎表明 rebake 将默认参数设置为 false,而 rebake! 将默认参数设置为 true。

这两个方法是如何关联的(顺便说一句,我知道 ! 字符在 ruby 中的含义),为什么它们会出现在不同的文件中?

我的目标只是想了解为什么我的外部图片有时上传成功,有时不成功,以及我是否能找到一种可靠的方法来自动正确地上传它们,即使这意味着每小时上传一张图片。 :sweat_smile:
我为此已经花了将近两周的时间,这让我(以及我为其迁移服务器的人)快疯了。 :woozy_face:

另外,Discourse 的日志中没有任何记录,只有多条 Sidekiq is consuming too much memory (using: 592.25M) 的提示。请注意,我是在 Windows 10 的 WSL 上通过 Ubuntu 进行操作的,但我打算在我们的 VPS 上使用一个有效的解决方案(如果我找到了的话……)。

1 个赞

它在下面第716行,你可以在那里看到它的作用。它会删除那些图片,以便重新下载它们。(至少乍一看是这样)

1 个赞

谢谢你的解释。 :slight_smile:


所以,我差不多花了 55 个小时,通过我的 rails 脚本,在每次迭代 40000 篇帖子时增加 5 秒的延迟来重新烘焙我的帖子,其中包含 [img]

从我看到的情况来看,它的效果比以前好得多。大多数有效的图片(我排除了 Imageshack 及其不稳定的行为)似乎都能完美上传到我的论坛,至少乍一看是这样,但我会更仔细地检查以确保 100% 确定。100% 确定的是,结果要好得多,也更一致。

所以,我怀疑我遇到的问题(也许还有 @Amethi问题),即使用 invalidate_broken_images 时远程图片下载的随机性,与来自各种图片托管提供商的某种速率限制有关……? :thinking: 奇怪的是,我在其他导入的论坛上没有注意到任何问题…… :face_with_raised_eyebrow:


话虽如此,如果结果足够令人满意,并且延迟确实改善了远程图片下载,我将在我的生产论坛上采用相同的方法,但我会将每次重新烘焙帖子之间的时间从 5 秒增加到 10 或 15 秒(甚至可能更长,我们不着急,这些都是相当旧的帖子,而且 VPS 的配置远低于我的电脑)。

我不想过早下结论,但解决我最初问题的 可能 方法是同时应用 Richard 提出的 解决方案 在每次帖子重新烘焙之间增加延迟。

3 个赞

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.