はい、その方向に完全に踏み込むと、Discourse でのコンテンツ編集機能を犠牲にして、完全な HTML の整合性を保つ必要があります。
私は、インポートされた HTML 投稿の img タグにのみこのアプローチを適用するという、中間的な解決策があるのではないかと考えていました。
しかし、今では自分で自分の考えを疑っています。これを部分的に適用するには、投稿処理の多くの部分で変更が必要になります。
「いいね！」 2
そうですね、これがおそらく最善の選択肢だと思います。私は 2020 年 6 月に着手したのですが、作業量が膨大になり、他のプロジェクトに移らざるを得ませんでした。\u003cimg タグ内で upload:// URL を許可するためのいくつかのアプローチを試しましたが、どれも完璧ではありません。私のメモによると：
実装案 1:
Markdown パイプライン内で、各 html_block の内容を解析し（xss.js ライブラリを少し乱用して）、upload:// 属性を持つ画像タグを処理します。
メリット: すべて Markdown パイプライン内で完結し、html_block トークンに対してのみこの処理を行います。
デメリット: xss.js サニタイザーを誤用している感じがあります。完璧な HTML5 パーサーではないかもしれません。
このオプションは、サーバー上で標準準拠の JavaScript DOM 実装（例: jsdom）を使用することで改善できますが、かなり重たいアプローチのようです。
実装案 2:
Markdown パイプライン全体で upload:// src 属性を許可し、後で置換します。クライアント側では実際には非常にシンプルです。調理（cooking）後に非同期で upload:// URL を置換していました。サーバー側では、Nokogiri を使用して追加の処理ステップを実行します。
メリット: パーサーが HTML5 標準準拠である。
デメリット: クライアントとサーバーで実装が異なり、パイプラインが少し複雑になります。
私はオプション 2 が進むべき道だと思います。その後、pull_hotlinked_images ジョブを更新して、Markdown に置換することなく \u003cimg タグを維持する必要があります。この作業にすぐに戻れる時間を見つけられることを願っています 
「いいね！」 4
ここでの複雑な点がよくわかりません。明らかに、HTML の画像タグが Markdown に置き換えられています（例：）。なぜ ! の前に改行を 2 回含めるようにしないのでしょうか？そうすれば正しくレンダリングされ、画像アップロード機能も機能して、画像の破損やクロスサイト問題を防げます。
その空白が問題を引き起こすような、現実的で理論的ではない状況は実際に存在するのでしょうか？その問題が、現在のプラグインで「画像が常に破損している」という状態よりも深刻だと言えますか？
@david さんは、「改行による解決策は実現しないだろう」と指摘し、「私たちの重要な点はコンテンツの整合性を保つことだ」と述べています。しかし、タグを挿入する時点でコンテンツはすでに変更されているはずです。……これがなぜより良いのか、本当に理解できません。
現状では、WordPress の投稿に画像を含めるたびに画像が破損してしまい、「画像が破損している」というコメントに対応せざるを得ず、最近ではそれに対して「はい、Discourse がダメだからです」といった返信が来ることも増えています。この 2 つの事態を避けたいのです。
「画像をダウンロードしない」という設定が回避策になることは理解していますが、実際には画像のダウンロードを希望しています。そのため、その設定は一時的な解決策に留まればよいと考えています。
「いいね！」 1
これは以下で解決されるはずです。
ここで試してみましょう。
<div>
Image in an HTML block:
<img src="..." width=100 height=100>
</div>
「いいね！」 6
このトピックは5日後に自動的に閉じられました。返信はもう許可されていません。