是的，如果你完全朝那个方向走，就得在无法编辑 Discourse 内容和保持完整 HTML 完整性之间做出取舍。
我在想，也许可以折中一下，仅对导入的 HTML 帖子中的 <img> 标签应用这种方法。
不过我现在又开始犹豫了。如果选择性这样做，就需要对帖子处理的多个部分进行修改。
2 个赞
是的，我认为这可能是最佳方案。我曾在 2020 年 6 月着手开始这项工作，但最终发现工作量巨大，不得不转向其他项目。我当时考虑过几种在 <img 标签中允许 upload:// URL 的方法……但都没有完美方案。以下是我的笔记：
方案一：
在 Markdown 管道中，解析每个 html_block 的内容（通过轻微滥用 xss.js 库），并处理带有 upload:// src 属性的任何图片标签。
优点：全部在 Markdown 管道内完成，仅对 html_block 令牌进行此处理。
缺点：有点误用 xss.js 清理器。它可能不是一个完美的 HTML5 解析器。
此方案可以通过在服务器端使用符合标准的 JavaScript DOM 实现（例如 jsdom）来改进，但这似乎相当臃肿。
方案二：
允许 upload:// src 属性贯穿整个 Markdown 管道，稍后再进行替换。在客户端，这实际上非常简单——我们已经在烹饪后异步替换 upload:// URL 了。在服务器端，这需要使用 Nokogiri 进行额外的处理步骤。
优点：解析器符合 HTML5 标准。
缺点：客户端和服务器端的实现不同，使管道稍微复杂一些。
我认为方案二可能是正确的方向。接下来，我们需要更新 pull_hotlinked_images 作业，以保留 <img 标签，而不将其替换为 Markdown。希望我很快能找到时间重新投入这项工作：
4 个赞
我真的不太理解这里的复杂性。显然，HTML 图片标签正被替换为 Markdown 格式——例如 。为什么不直接在 ! 之前加上两个回车符呢？这样既能正确渲染，又能让图片上传功能正常工作，从而避免图片损坏和跨站问题。
是否存在某种现实世界（而非理论）的情况，会导致这种空白字符引发问题？如果有，这个问题是否比当前插件中“图片总是损坏”的状态更严重？
@david，你提到“添加空行的方案可能不会实施”，因为“对我们来说关键是要保持内容的完整性”。但内容在插入标签的那一刻就已经被改变了。我……真的不明白这怎么可能更好。
目前，_每次_有人在 WordPress 帖子中包含图片时，这些图片都会显示为损坏，我经常需要处理“图片损坏”的反馈，而且现在这些反馈后面往往还跟着“是的，这是因为 Discourse 太烂了”的评论。我希望避免这两种情况。
我理解“不下载图片”的设置可能是一个变通方案，但实际上我_确实_希望图片被下载，所以希望这能只是一个临时解决方案。
1 个赞
这应该通过以下方式解决：
让我们在 Meta 上试试。
<div>
Image in an HTML block:
<img src="..." width=100 height=100>
</div>
6 个赞
此主题已在 5 天后自动关闭。不再允许回复。