より詳しい情報を提供したいところですが、残念ながら利用可能な最も役に立たないエラーメッセージしか手元にありません。
この投稿を Discourse に公開する際にエラーが発生しました。
サイト側でも Discourse 側でも、エラーログには何も表示されていません。
既存のトピックへのリンクは貼れますが、それは投稿メタデータを直接更新するのとほとんど同じ程度の助けにしかなりません。
設定で何か見落としているデバッグスイッチはありませんか？あるいは、有用なエラーメッセージを取得できる別の方法はありませんか？
こんにちは @invisnet さん
ブラウザの Web 開発者ツール（コンソール）を開いて、JS コンソールにエラーが表示されていないか確認されましたか？
現在、特に目立ったものはなく、Discourseに関する内容もありません。
本来見る必要のないところをあれこれ掘り下げた結果、以下のエラーメッセージが得られました：
Can’t verify CSRF token authenticity.
これは、元のメッセージとほぼ同じくらい役立ちません。
このことから、私は次のように結論付けました：
embed_url をトピックに対して手動で設定する方法がないため、この問題が修正されるまで私は行き詰まっているまあ、一種の解決策といえばそうなのかもしれない……
返信が遅くなり申し訳ありません。Support > WordPress カテゴリは監視していますが、このトピックの通知は受け取っていないと思います。
詳細なエラーメッセージを取得する最も簡単な方法は、Query Monitor – WordPress plugin | WordPress.org English (Canada) をインストールし、その後、Discourse への投稿を試みることです。WP Discourse プラグインは以前、すべてのエラーをログファイルに保存していましたが、WordPress の推奨事項に反するため、その機能は停止しました。
Discourse への投稿を試みるときにエラーが発生しますか、それとも特定の投稿でのみ問題が発生していますか？
Discourse 2.6.0.beta1 へのアップグレードが問題の原因である可能性は低いと思われます。プラグインが機能しなくなった時期に、WordPress サイトに変更を加えましたか？
エラーは Docker コンテナ内の production.log にのみ表示され、他のログやコンソールには何も表示されません（すでに Query Monitor を実行しています）。
新しい投稿すべてで発生します。
プラグインを 2.0.6 に更新しただけです。ただし、問題はプラグインではありません。git タグを遡っても解決しませんでした。
Query Monitorプラグインがエラーを表示していないことに驚いています。エラーメッセージが異なるものの、以下のような表示を期待していました：
Discourseの管理画面/APIページから新しいAPIキーを生成してみる価値があるかもしれません。その際、キーが「Global Key」（すべての操作を許可する）であることを確認してください。また、WP Discourse接続設定タブで「Publishing Username」が正しく設定されているかも確認してください。既存のDiscourseトピックへのリンクは作成できるものの、新しいトピックの公開ができない状況から、APIの権限に関連する問題である可能性が考えられます。
もう一つ確認すべき点として、WordPressからDiscourseへの投稿を試みるときに、投稿のカスタムフィールドにどのような値が設定されているかを確認してください。エディタでカスタムフィールドを有効にすると、エディタの下部に以下のような表示が現れるはずです：
設定されているフィールドについて教えていただければ、問題の原因を特定できるかもしれません。
私も同感ですが、実際には何も表示されていません。もし表示されていれば、production.log に報告されている通り 400 エラーだったはずです。しかし、表示されていません。
更新: コードをくまなく調べてみたところ、エラーは発生しないことがわかりました。すべて捕捉されているからです。メールレポートを有効にすると（メールは送信されるが error_log() は呼ばれない場合）、以下のように表示されます:
失敗の理由:
Discourse から 400 のレスポンスコードが返されました。
Bad Request
しかし、それだけです。
すでに実行済みですが、変化はありません。これは最後の手段でしたが、前のキーの「最終使用日時」が投稿を試みた際に更新されていたため、キーが何らかの原因で変更されていないことは確実でした。それでも試してみる価値はあると考えました。
publish_post_category: 23
update_discourse_topic: 0
wpdc_publishing_error: Bad Request
wpdc_unlisted_topic: 1
以上です。念のため尋ねておきますが、「未公開として公開」を設定しない場合でも同じ現象が発生します。ただし、投稿メタデータの値は当然異なります。
詳細をありがとうございます。月曜日に仕事に戻り次第、改めて確認いたします。
400 レスポンスの原因が何なのか確信が持てません。Health Check & Troubleshooting – WordPress plugin | WordPress.org English (Canada) をインストールして、WordPress サイトに問題がないか確認してみてください。このプラグインを有効化すると、WordPress ダッシュボードの「ツール」セクションに「サイトヘルス」という項目が追加されます。そのリンクをクリックし、「ステータス」タブに移動すると、役立つ詳細情報が表示される場合があります。
ヘルスチェックプラグインでは、自分のセッションのみで一時的にプラグインを無効化することも可能です。これは、他のプラグインとの競合が原因かどうかを確認するのに役立ちます。サイトにセキュリティ関連のプラグインがインストールされている場合は、それらを無効化して問題が解決するかどうか確認してみる価値があるかもしれません。
残念ながら行き詰まってしまいました。Health Check プラグインは役に立つ情報を何も示さなかった（当然ですが）、それ以外の部分はすべて正常に動作しています。
招待状の自動送信を自動化している際に CSRF エラーに遭遇しました。これは通常、コードにミスがあることを意味しますが、今回の場合、プラグイン自体に変更はありません。したがって、私の結論としては 2.6.0.beta1 が壊れているということです。
それが一般的な見解ではないことは承知していますが、現時点ではそれが唯一の結論です。
追記：他のすべてのプラグインを無効にするために Health Check プラグインを使用しましたが、結果に変化はありませんでした。
2.6.0.beta2 および 2.1.2 でも問題が継続しています。
