こんにちは。
当社のウェブサイトでWP Discourseプラグインに問題があることに気づきました。
基本的に、ブログ記事を公開し、それがDiscourseフォーラムで正常に公開された後、例えば1週間後に記事にわずかな変更を加えて更新すると、WP Discourseプラグインはそれをフォーラムに再度公開しようとします。
その結果、「Discourse Publishing Failure」という件名のメールが届き、「埋め込みURLは既に取得されています」と表示されます。
非常に古いWordPressの記事を更新した場合にも、Discourseフォーラムのデフォルトカテゴリ「News」に表示され、読者を混乱させるという問題も確認しました。
これを回避するために、私が設定を見落としているものはありますか？
どうぞよろしくお願いいたします。
レポートありがとうございます。このシナリオについては、早ければ明日、遅くとも来週初めには詳しく確認します。
@npm0912 さん、テストをお願いできますか？
この問題を再現しようとしていただけますか？ただし、変更を加える前に（1週間後、または通常の期間経過後に）、投稿編集画面の右側にあるWordPressユーティリティバーでDiscourse投稿のステータスを確認してください。編集を行う時点でそこに何が表示されているか、そして編集後に説明されている動作が発生するかどうかを教えてください。
WP Discourseのログのダウンロードも共有していただけると幸いです。
10日ほど前に公開された投稿を編集しようとすると、このDiscourseの投稿ステータスが表示されます。
投稿を更新しようとしましたが、同じエラーが発生しました。失敗に関するメールも届きました。
ログからの最後のエラーは次のとおりです。
[2024-05-13 18:02:53] publish.ERROR: create_post.post_error {"wp_title":"Nextcloud exhibiting at global events in May 2024","wp_author_id":"9","wp_post_id":209030,"response_message":"Embed url has already been taken","http_code":422}
投稿がすでにDiscourseに存在する場合に、再公開の試みを無効にする設定ページ上のオプションがあるべきではないでしょうか？
よろしくお願いします！
Ok、これは、WordpressインスタンスがWP Discourseプラグインに投稿メタフィールドを正しく保存させず、サイト上の別のプラグインまたはテーマが原因である可能性が高いことを意味します。WP Discourseログのダウンロードを共有していただけますか？それには、原因を示唆する可能性のあるプラグインのリストが含まれます。
通常、プラグインは最初の公開後に公開詳細を保存します。あなたのサイトではそれが起こっていません。それを解明する必要があります 
わかりました、それは奇妙ですね。バグだと思っていました。メタデータファイルを添付します。これで十分かどうか教えてください。
wp-discourse-logs-metafile-2024-04-17-2024-05-13.txt (2.5 KB)
Discourseプラグインと干渉する可能性のある既知のプラグインがあれば教えてください。
この調査に時間を割いていただき、本当にありがとうございます！
原因となっている可能性のあるプラグインがいくつかあります。まず、WP Discourse の「Publishing」設定でこの設定を有効にしていただけますでしょうか。
これにより、プラグインがカスタムフィールドを保存する方法が変更され、お客様の場合の動作に影響を与える可能性があります。おそらく問題は解決しませんが、より多くの洞察を得られるかもしれません。有効にしたら、同じ状況を再現してみてください。
それを試した後、個々のプラグインを無効にして問題を特定できるかどうかを確認します。ステージングサイト（テーマとプラグインはありますが、実際のデータはないサイト）はお持ちですか？
また、プラグインの公開ロジックにさらに多くのログを追加して、この種の（つまり、Discourse への公開後の WordPress へのメタデータの保存）問題を解明するのに役立てます。ただし、それには時間がかかるため、その間、上記のようなテストを実行できます。
こんにちは、そして改めてお時間をいただきありがとうございます！
その設定を有効にしましたが、問題はまだ残っています。
実際にはステージングサイトを使用しており、面白いことに、プラグイン、テーマ、ファイルがまったく同じであっても、動作が異なります。つまり、テスト投稿を公開した後、Discourse に正しく投稿され、その後同じ投稿に戻ると、Discourse サイドバーの設定で「Embed url has already been taken」というエラーは表示されません。代わりに次のように表示されます。
サーバーの違いは次のとおりです。
ステージングサイト:
WordPress - 6.5.3
PHP - 8.1.27
MySQL - 10.6.16
本番サイト:
WordPress - 6.5.3
PHP - 8.1.2-1ubuntu2.17
MySQL - 5.5.5
@npm0912さん、これは問題があなたの環境によるものであることを示しています。
こんにちは、@angus さん
はい、ログはこちらです。
ステージング:
Staging wp-discourse-logs-metafile-2023-04-13-2024-05-28.txt (2.4 KB)
本番サイト:
LIVE wp-discourse-logs-metafile-2024-05-13-2024-05-28.txt (2.4 KB)
Discourseインスタンスは同じで、ステージングから別のフォーラムカテゴリに投稿している点が異なります。
両方のインスタンスでWP RocketとRedisキャッシュを使用しているため、これが影響しているとは考えにくいです。
よろしくお願いします！
いくつかわずかな違いがあります。おそらく原因ではありませんが、ステージングサイトと本番サイトを同一に保つことは、ここでの原因だけでなく、他の問題の原因を排除する価値があります。
それ以外では、WP Rocketの設定を注意深く確認することをお勧めします（例：両方のサイトで実際同じ設定になっていますか）。WP Rocketは特定の目的に対してうまく機能しますが、WordPressプラグインの問題の原因となることがよくあります。
WordPressでは現在、MySQLバージョン8.0以降が必要です。本番環境のデータベースをアップグレードする必要があります。
相互参照: Could not update the meta value of discourse_post_id in database - #2 by angus
WP Discourse は DB に関する情報を間違っていました。データベースの正しいバージョンは 10.6.16-MariaDB-0ubuntu0.22.04.1 です。
そのファイルに表示されているバージョンは、WordPressのコア関数の出力です。
$wpdb->db_version()
コードはこちらで確認し、さらにこちらを参照してください。
これがWordPressが使用していると考えているバージョンです。これが問題のようです。
おっしゃる通りです。テーマ内のdb_version()関数を再度確認したところ、確かに5.5.5という結果が得られました。しかし、「サイトヘルス」のバックエンドページでは、システム管理者が言及していたバージョンと同じ10.6.16-MariaDBと表示されています。これもWordPressが見ているバージョンと同じはずですよね？
申し訳ありませんが、サーバーを確認せずに、ここで何が起こっているのかを自信を持って言うことはできません。
報告された問題点を考慮すると、この点を徹底的に調査することをお勧めします。
