これは、Discourse の設定ページの「ログイン」セクションから行うことができます。「ログインが必要」設定を選択することで、匿名ユーザーがサイトを閲覧できないようにできます。
これは、WP Discourse プラグインがあなたの Discourse サイトに対して API 呼び出しを行えることを意味しますが、WordPress サイトが Discourse からのリクエストを許可していることを意味するわけではありません。「フル投稿を表示」ボタンをクリックすると、Discourse は投稿内容をスクレイピングするために WordPress サイトに対してリクエストを送ろうとします。このリクエストがブロックされている可能性が高いと思われます。
貴重な情報をありがとうございます。ログインを無効化しました（素晴らしいヒント！）。メインサイトを最終的に公開する際にどうなるか様子を見ることにします。もしかすると、その時点で「全文を表示」ボタンが正しく有効になるかもしれません。
Onebox についてですが、https サイトでのみ機能するのでしょうか？
リンクが Onebox を形成するにはいくつかの要件があります。現在 HTTPS が必須かどうかは確信が持てませんが、もし必須になっていたとしても驚きません。その他の要件として、リンク先のページに Open Graph 記述タグが設定されていること、そして Discourse サーバーからのリクエストが通過できるように設定されていることが必要です。おそらく、あなたのステージングサイトには Onebox の生成を妨げるいくつかの問題があるのではないかと推測します。
こんにちは、サイモンさん。
なるほど、その通りですね。メインサイトを公開したら、もう一度Oneboxingを試してみます。
前述の通り、サイトを公開してステージング環境から外すことで、Discourseへの投稿機能も改善されることを願っています。
引き続き、ご協力とご示知をいただきありがとうございます。
RSS フィードから取得された壊れた画像は、手動では修正できないようです。
エディタの右側のプレビューでは画像が再表示されているのが確認できますが、保存を押すと、投稿内の画像は依然として壊れたままです。
画像がローカルに存在しない場合、Discourse はサムネイルを生成しません。もし disabled image download domains を有効にすると、インポートされたすべての投稿にサムネイルが表示されなくなります。
私も同じ問題が発生しています。プレビューでは2つの画像が表示されますが、保存すると次のようになります：
プレビューだけでなく、投稿内でも画像が表示されるようになる解決策はありますか？
更新: 2.7.0.beta7
投稿を編集し、両方のマークダウンタグの上に空行を追加する必要があります。
Web サイトから Discourse に投稿を公開している場合は、画像が配信されているドメインを Discourse の「画像のダウンロードを無効化するドメイン」サイト設定に追加してください。これにより、Discourse に公開される新しい投稿で同様の問題が発生するのを防ぐことができます。
サイモン、ありがとうございます。残念ながら、うまくいきませんでした：
公開 URL をお送りすることはできますが、スパムとみなされるかどうかわかりません。必要であれば、PM で送ることも可能です。
さらに情報が必要であればお知らせください。
（現在は 2.7.0.beta7、890b06b10f）
追記：背景情報です。投稿は インポートスクリプト を通じて、Freshdesk フォーラムの XML エクスポートからインポートされました。実際のコンテンツには完全な HTML が含まれていました。その後、ローカル開発システムからのバックアップを新しい本番環境インスタンスにインポートしました。当初は画像が表示されていましたが、外部 URL を参照する元の img タグが含まれていたため、しばらくすると Discourse が外部のリモート画像をダウンロードしました。その結果、上記のように投稿が壊れて表示されるようになりました。
ここでの複雑な点がよくわかりません。明らかに、HTML の画像タグが Markdown に置換されています。例えば  のようにです。なぜ ! の直前に改行を 2 回含めるようにしないのでしょうか？そうすれば正しくレンダリングされ、画像アップロード機能も機能して、画像の破損やクロスサイト問題を防止できます。
その空白が問題を引き起こすような、現実的で理論的な状況は実際に存在するのでしょうか？その問題が、現在のプラグインで「画像が常に破損している」という状態よりも深刻なのでしょうか？
当社の WordPress プラグインでは、まさにその手法を用いて WordPress 側でこの問題を回避しようとしています。Discourse に投稿する前に、すべての HTML img タグの直前に改行を 2 回挿入することで、この問題は解決します。
以前、当社のマークダウンパーサーに同様の機能を追加することを提案したことがあります：https://meta.discourse.org/t/markdown-rendering-issue-with-image-surrounded-with-html/152801。しかし、そのアプローチが却下された理由は、CommonMark 仕様からの逸脱を避けたかったためだと考えています。
なるほど、ますます混乱してしまいました！これは演出ではなく、本当に困惑しているのです。
当社は Discourse をホストしており、WordPress 側には最新バージョンのプラグイン（2.3.0）が入っているはずですが、それでも画像が壊れて表示され、手動で空白行を追加する必要があります。これを有効にするために何か設定が必要でしょうか？
その通りです。これは混乱を招く問題です。WP Discourse プラグインは画像に関する問題を解決しようとしていますが、現時点では、WordPress ブロックエディタで投稿が公開され、デフォルトの画像ブロックを使用して投稿に画像が追加された場合のみ、画像を捕捉しています。WordPress サイトの投稿に画像を追加する方法について詳細を共有していただければ、この問題に対処する方法を見出せるかもしれません。
理想的には、Discourse 側でこの問題が修正されることを願っていますが、それが不可能な場合、WP Discourse プラグインが行う画像の解析を改善する必要があります。
ふむ、わかりました。Would you use this as your homepage? – Fedora Community Blog を見ると、https://discussion.fedoraproject.org/t/would-you-use-this-as-your-homepage/32123 に飛ぶようですね。（2 つ目のリンクの画像が機能するのは、私が投稿を直接編集したためです。）
WordPress のバックエンドを見ると、すべての画像は画像ブロックとして表示されています。
それでも、ここでの複雑さがなぜ必要なのか理解できません。Discourse サイトの各投稿の生テキストに  のような Markdown が追加されているのは、何かしらの処理によるものです。なぜその処理が、挿入される各 Markdown ブロックの前に空白行を追加しないのでしょうか？
関連するバグトピックでその質問を投稿してみてください：https://meta.discourse.org/t/markdown-rendering-issue-with-image-surrounded-with-html/152801。バグトピックで投稿すれば、より多くの注目を集める可能性が高いです。
追記：WordPress 側で画像の解析が正しく行われず、問題が発生している WP Discourse プラグインの件について、@angus に通知します。問題の特定には、あなたからさらに詳細な情報が必要になるかもしれません。
