simon
2020 年 8 月 13 日午後 6:20
1
WP Discourse プラグインと RSS プラグインを介して Discourse に公開された画像が破損する場合があります。これは、WP Discourse プラグインで投稿の全文を Discourse に公開し、WordPress のクラシックエディタを使用して投稿を公開した場合に発生します。また、RSS Polling によって Discourse に取り込まれた投稿で、「埋め込み投稿を切り捨てる」設定が有効になっていない場合にも発生します。
この問題は、Discourse が投稿に追加された画像のダウンロードを試みるときに発生します。リモート画像のダウンロード結果が HTML タグで囲まれた Markdown 画像タグになった場合、画像は破損します。
投稿が WordPress から公開されている場合、クラシックエディタの使用をブロックエディタの使用に切り替えることでこの問題は解決します。これが不可能な場合、または問題が解決しない場合は、Discourse がリモート画像をダウンロードしないようにすることが回避策となります。
リモート画像が公開されているドメインがわかっている場合は、そのドメインを「無効な画像ダウンロードドメイン」のサイト設定に追加することで、Discourse によるこれらの画像のダウンロードを防ぐことができます。
使用されているすべてのドメインが不明な場合は、「リモート画像をローカルにダウンロード」を無効にすることで、Discourse によるすべてのリモート画像のダウンロードを防ぐことができます。ただし、この設定を無効にすると、サイト上で画像が破損する可能性があります。可能であれば、特定のドメイン（あなたが管理しているドメイン）からのリモート画像のダウンロードのみを防ぐことをお勧めします。
「いいね！」 5
maiki
2020 年 8 月 13 日午後 9:23
2
これについてもう少し詳しく教えていただけますか？私のすべてのサイトはクラシックエディターを使用していますが、Markdown を入力としてレンダリングするプラグインを使用しているサイトはごくわずかです（Markdown パーサーのプラグイン市場は縮小しており、人々はほとんどの場合 Jetpack に頼っています）。
これはクラシックエディターの上に Markdown パーサーを使用している場合のことでしょうか？
simon
2020 年 8 月 13 日午後 9:37
3
maiki:
これについてさらに詳しい情報をいただけますか？
この問題は、以下の形式の HTML が Discourse に投稿された際に発生します。特に、トピックが API を通じて Discourse に投稿される場合に起こりやすいです。
<p><img src="remote-image-domain/..."/></p>
画像タグを囲む外部タグ（例：<figure><img src="remote-image-domain/..."/></figure>）があると、この問題が発生します。
Discourse がリモート画像のダウンロードを試みると、最初の例に対して以下の Markdown が生成されます。
<p></p>
これにより、画像の表示が壊れてしまいます。手動で Discourse の投稿を以下のように編集することで修正可能です。
<p>
</p>
ただし、サイト設定の「disabled image download domains」を使用して、Discourse によるリモート画像のダウンロードを無効化するのが、より簡単な解決策です。
WP Discourse プラグインのブロックエディタから投稿された記事の場合、プラグインは公開前に以下のコードで投稿を処理することでこの問題を修正しようとします。
/**
* Extracts image src from HTML and returns an image tag for each image.
*
* This function is used when full post content is published to Discourse. Its purpose is to remove the surrounding
* <figure> tags from images. Unless that is done, images will break when they are downloaded by Discourse.
*
* @param string $html The HTML to extract the image URL from.
*
* @return string
*/
protected function extract_images_from_html( $html ) {
if ( ! extension_loaded( 'libxml' ) ) {
return $html;
}
$use_internal_errors = libxml_use_internal_errors( true );
$disable_entity_loader = $this->libxml_disable_entity_loader( true );
$doc = $this->create_dom_document( $html );
$finder = new \DOMXPath( $doc );
show original
クラシックエディタでも同様の修正を実装できる可能性はありますが、クラシックエディタでは WordPress の parse_blocks 関数が利用できないため、修正はより複雑になります。最終的には、Discourse コアコードの変更によってこの問題が解決されることを期待しています。
「いいね！」 3
maiki
2020 年 8 月 14 日午後 6:53
4
サイモン、ありがとうございます！問題が理解できました。素晴らしい説明ですね。
「いいね！」 1
Don
2020 年 10 月 25 日午後 2:05
5
こんにちは、Simon さん。WP Discourse を作成していただき、ありがとうございます。
私も画像で同じ問題に遭遇しました。画像をローカルにダウンロードする機能を使用していたところ、上記で説明されているように画像が破損してしまいました。その後、WordPress の HTML を Markdown に変換し、変換したものを手動で Discourse に貼り付けています。動作は問題ありませんが、手動での作業です。
ありがとうございます！
「いいね！」 1
simon
2020 年 11 月 2 日午後 7:07
6
投稿の公開に WordPress ブロックエディタを使用している場合、変換は自動的に実行されます。クラシックエディタを使用している場合は、画像の破損を防ぐために、Discourse 側で HTML を手動で修正する必要があります。
ブロックエディタを使用しているにもかかわらず、画像の破損に問題がある場合は、お知らせください。
クラシックエディタで公開された投稿にも同様の機能を追加することは可能ですが、そのために必要なコードは、ブロックエディタで実装されているものよりも複雑なものになります。
「いいね！」 1
Don
2020 年 11 月 2 日午後 7:11
7
ブロックエディタ（Gutenberg）を使用していますが、そこにサードパーティ製のプラグインがいくつかインストールされています。それが画像の破損の原因かもしれません。また、WordPress でもいくつかのサードパーティ製のギャラリープラグインを使用しています。
simon
2020 年 11 月 2 日午後 7:18
8
ギャラリープラグインが問題の原因である可能性があります。WP Discourse プラグインは、Discourse に公開される投稿コンテンツを設定する前に、投稿内の blockName が core/image または core/gallery に設定されている blocks を検索します。これらのブロック内の画像の HTML は、Discourse で解析可能な形式に書き換えられます。
お使いのサイトで使用されている画像プラグインが、処理されていないブロック名を使用している可能性があります。現在使用されているギャラリープラグインの名前は何ですか？
Don
2020 年 11 月 2 日午後 7:28
9
なるほど…これを使っているのですが、今になってすでにサポートされていないことに気づきました。そのため、画像をデフォルトのギャラリーに戻して、Discourse のトピックを更新しようと思います。これが問題の原因だったかもしれません。申し訳ありません。
「いいね！」 1
Canapin
2020 年 11 月 16 日午後 8:05
10
ブロックエディタに切り替えました（来年にはクラシックエディタのサポートが終了するため、いずれは切り替える必要がありますが）、それでも問題は解決しませんでした。画像は Facebook にホストされていました。
simon
2020 年 11 月 17 日午前 12:21
11
WordPress の投稿でサイドバーから「コードエディター」を選択して、画像のマークアップを確認できますか？私が知りたいのは、画像がどのようなブロック（あれば）に入っているかです：
WordPress プラグインは画像を解析するためにブロック名を使用しています。もし画像がプラグインが現在処理しているブロックに入っていない場合、そのマークアップは整理されません。
「いいね！」 1
Canapin
2020 年 11 月 17 日午前 12:32
12
WP の投稿は Facebook からのコピー＆ペーストでした。HTML コードのサンプルを以下に示します。
<div dir="auto"><span class="pq6dq46d tbxw36s4 knj5qynh kvgmc6g5 ditlmg2l oygrvhab nvdbi5me sf5mxxl7 gl3lb2sf hhz5lgdu"><img src="https://static.xx.fbcdn.net/images/emoji.php/v9/t34/1/16/1f914.png" alt="🤔" width="16" height="16"></span>Comment ? Vous avez 1 mois pour nous envoyer vos plus beaux poèmes et/ou dessins sur le thème du monocycle, ce qu'il vous évoque, votre passion pour ce sport, etc.</div>
ブロックエディターでは、あなたと同じサイドバーが表示されないため、このオプションを使用してブロックの HTML コンテンツを表示しました。
もしこの問題が「通常の」WP コンテンツではなく、HTML のコピー＆ペーストが原因で発生しているなら、それは問題ではありません。ユーザーには、画像（絵文字を含む）のコピー＆ペーストを避けるように伝えます。
「いいね！」 1
simon
2020 年 11 月 17 日午前 12:42
13
はい、ここで問題となっているのは、HTML が WordPress の投稿にコピーされたことです。WP Discourse プラグインは、画像ブロックを通じて追加された画像を処理できるようになっていますが、他の方法で追加された画像の HTML を修正するようには設定されていません。
理想的には、Discourse が他の HTML タグで囲まれた HTML 画像タグを処理できることが望ましいのですが、これは難しい問題です。おそらく WP Discourse プラグインを、画像ブロック以外で追加された画像を処理できるように更新できるかもしれません。当初は画像ブロックへの対応で大半のケースをカバーできると考えていましたが、どうやらその例外が非常に多いようです。
「いいね！」 3
こんにちは、
このトピックと、画像に関する他の主要なトピックを読み終わりました。
私のサイトから抜粋を Discourse に公開するのは完璧に動作します。しかし、「完全な投稿を表示」ボタンをクリックすると、読み込みループに入り、完全な投稿（あるいは他の何らかの動作）が一向に読み込まれないようです。
完全な投稿を Discourse に公開しようとすると、いくつかの奇妙な挙動はありますが、動作します：
画像が読み込まれない（これによりこれらのトピックにたどり着きました）。
完全な投稿が読み込まれます（各投稿のコンテンツ内にいくつかのボタンやリンクがあり、プラグインを混乱させている可能性があります）。しかし、何らかの理由で、完全な投稿の末尾に、見事にフォーマットされた投稿の抜粋も読み込まれてしまいます。つまり、完全な投稿（画像を除く）が読み込まれた後、同じ投稿の別の抜粋が投稿の下部に読み込まれてしまいます。
一点注意すべき点として、私の WP サイトはステージングモードで、HTTPS ではありません。一方、Discourse サイトは HTTPS です。完全な投稿の読み込みがステージングサイトとの相性問題ではないかと考えましたが、他の機能（例：カテゴリ更新の強制）は問題なく動作しています。
これは複雑な問題であることは理解しています。誰もが異なることを行っている中で、プラグインが他者の投稿をフォーマットするのは非常に困難であり、Discourse チームが素晴らしい成果を上げたことは認めざるを得ません。私はできるだけシンプルな回避策を探しているだけです。もしかしたら、投稿へのリンクをワンボックス化するだけでよいのでしょうか？そうすれば、少なくとも投稿（またはそのリンク）は Discourse サイト上に存在することになりますが、双方向の連携は行われなくなります。
ご提案があれば、ぜひお聞かせください。
simon
2021 年 1 月 19 日午後 11:09
15
問題は、Discourse が WordPress ページ上のコンテンツを検出できないことにある可能性があります。ただし、それがループを引き起こすとは考えにくいです。Discourse はページにコンテンツが見つからない場合、静かに失敗するはずです。もしコンテンツのない投稿でテストしている可能性がある場合は、実際のテキストを含む投稿を作成して、違いがあるか確認してみてください。また、許可された埋め込みセレクター設定の構成方法 も参照してください。「許可された埋め込みセレクター」設定を使うと、Discourse がページのコンテンツを見つけるのを支援できます。
WordPress の投稿を公開する際に、ブロックエディターを使用していますか？もしそうなら、画像はどのように投稿に追加されていますか？カスタム画像ブロックを追加するプラグインを使用していますか？
読み込まれる投稿抜粋には、投稿の画像が含まれていますか？
ここで抜粋が自動的に読み込まれるとは思いません。期待されるのは、「完全な投稿を表示」ボタンが表示されることです。そのボタンをクリックすると抜粋が読み込まれます。WordPress から Discourse に完全な投稿コンテンツが公開される場合、Discourse の embed truncate サイト設定を無効にすることで、「完全な投稿を表示」ボタンの表示を防止できます。
これはあなたにとって良い解決策になるかもしれません。投稿を公開する際に使用されるテンプレートをカスタマイズする方法については、Customize the structure of WP Discourse templates をご覧ください。投稿をワンボックスとして公開するためのテンプレートの例はこちら にあります。
こんにちは、
Simon さん、迅速なご返信をありがとうございます。
ご提案いただいた内容を試してみましたが、結果は変わりませんでした。これはおそらく Discourse の操作スキルに問題があるのだと思います。
最初の提案として、投稿に何らかの内容が含まれていることを確認するようにとのことでした。投稿には実際の内容が含まれていたため、それが問題だったとは考えにくいです。また、「許可された埋め込みセレクターの設定」の構成方法についてもご提案いただきましたが、これも実施したものの、まだ変化は見られません。この設定は非常にシンプルに保ち、<p> タグと他の 1 つ（かなり汎用的な）CSS クラスを含めましたが、「全文を表示」をクリックしても、まだ「読み込み中」と表示されたままです。
私はブロックエディターを使用しています。特定の画像プラグインはインストールしていませんが、Genesis Blocks は使用しています。ただし、Discourse が読み込もうとしている画像は、投稿の「表紙画像（Featured Image）」であり、これは標準的な WordPress の機能だと認識しています。
ご質問の「読み込まれる投稿の抜粋に画像が含まれていますか？」という点については、いいえ、投稿には画像が含まれていません。ただし、画像が表示されるべき場所をクリックすると、元の投稿記事へリンクされます。
Oneboxing オプションについてもさらに調査いたします。それに関連するトピックへのリンクも提供いただき、ありがとうございます。
simon
2021 年 1 月 20 日午後 9:21
17
その画像に関する問題の原因はそれかもしれません。確認してみます。
この状況の原因ははっきりしません。あなたの Discourse サイトが公開されている場合、問題が発生しているトピックへのリンクを共有してもらえませんか？もしよろしければ、PM で送ってください。
改めてありがとうございます。サイトはまだステージング環境にあり、公開されていません。これが問題の原因でしょうか？
また、何らかの理由で「ワンボックス化」が機能しません。例えば CNN.com からのリンクを貼り付けると正常にワンボックス化されますが、私のステージング環境（非 HTTPS）のサイトからのリンクを貼り付けると、単にリンクとして表示されるだけです。これはステージングサイトが安全でない（HTTPS ではない）ためでしょうか？
simon
2021 年 1 月 20 日午後 9:30
19
Discourse サイトを非公開にしても問題にはなりません。WordPress サイトを何らかの方法で非公開にしていませんか？WordPress サイトが Discourse からのリクエストをブロックして、投稿の全文を取得できない場合、問題が発生します。
Discourse サイトは公開状態です。開発中は非公開にしたいのですが、ステージングする方法がわかりません。メインの WordPress サイトはステージング/開発中で、そのサイトは非公開/隠されています。
WordPress プラグインからカテゴリの更新を強制することは可能です。メインのサイトがステージング状態であっても、Discourse がメインのサイトに接続できることを意味するのだと思いますが、おそらくそれは誤解かもしれません。
