wordpressプラグインのバグトラブルシューティングの追記（この記事は自分用に書いています）

この記事は私自身のために書いています。

水曜日、会社のWordPressプロジェクトページを管理しているときに非常に奇妙な状況を発見しました。Webサイト上のページを更新しようとしたとき、WordPress背景のエディタでそのコンテンツのURLが期待どおりではないことがわかりました。画像が置き換えられました (Web サイトで Baidu Cloud プラグインが有効になっており、プラグインは記事内の画像をキャプチャし、その画像を Baidu Cloud にアップロードして、記事内のアドレスを置き換えます)。フロントページを確認すると、表示されているページの画像URLも置き換えられていることがわかりました。つまり、フロントエンドの記事表示ページとバックエンドエディタのコンテンツが置き換えられています。一貫性がない。このバグは本当に奇妙です。今後の参考のために、このバグのトラブルシューティングのプロセスを記録します。

1. Web サイトには、Baidu Cloud プラグインと競合する他のプラグインがある可能性があります

ウェブサイトには多くのWordPressプラグインがインストールされているため、これは実際に可能です。しかし、よく考えてみると、Baidu Cloud プラグインと競合するプラグインは他にないようです。

2. 技術責任者と協力して、データベース内の wp_posts テーブルを使用してトラブルシューティングを行います

wp_posts テーブルの構造は次のとおりです:

このテーブルの次のフィールドは非常に重要です:

post_status (記事のステータス) の値は次のとおりです:trash (ごみ箱)、publish (公開)、inherit (継承)、draft (下書き)、auto-draft (自動的に保存された下書き)

post_type (記事タイプ) の値は次のとおりです: post (記事)、page (ページ)、revision (リビジョン)、attachment (添付ファイル)、nav_menu_item (メニュー)

post_parent (親投稿の ID)。

post_status はこの記事が公開されているかどうかを決定し、post_type はレコードがドラフト、記事、ページ、または記事の改訂版であるかどうかを決定します。記事は何度も変更できるため、多くのリビジョンが含まれます。 post_parent には、現在のレコードの親記事の ID が格納されます (これは、post_status が継承またはドラフトの場合にのみ使用され、その他の場合のデフォルトは 0 です)。

デバッグ プロセスは基本的に次のようになります。「更新ボタン」をクリックするたびに、wp_posts テーブル内のレコードの変更が表示されます。結果は次のとおりです。

(1) ウェブサイト上で公開されたページ（ID が 1234 であるとします）について、データベース内の対応するレコード（post_status が公開、post_type が page）が正常に変更されました。これは、エディタ内のコンテンツがレコード 1234 ではなく、ID=1234 の記事の改訂版であることを示している可能性があります。何度か確認した結果、それは本当であることがわかりました。

(2) では、どのリビジョンが適用されるのでしょうか?いくつかの調査の結果、エディターは常に最新のリビジョンよりも前のリビジョンを取得することがわかりました。正確な説明は次のようになります。更新をクリックするたびに、データ テーブルにリビジョンと自動ドラフトが表示されます。最新リビジョンの記事の内容は、置き換えられた img src の正しい内容です。 auto_draft はエディターのものと同じです。エディター状態では、WordPress は頻繁に自動保存し、新しい自動ドラフトが生成されるたびに、前の自動ドラフトは削除されます。エディターがコンテンツを取得するとき、自動ドラフトからは取得しません。つまり、どの改訂に基づいたものなのかは最終的には明らかではありませんでした。ただし、ID=1234 の投稿内容と一致するように、最新のリビジョンを適用する必要があります。

3. キャッシュはどうなりましたか?

ブラウザのキャッシュが原因ではないかと疑い始め、ブラウザのキャッシュをクリアしようとしたところ、問題がまだ存在していることがわかりました。これはサーバー側のキャッシュです。サーバー上で memcached を再起動します。service memcached restart を実行すると、エディターのコンテンツが正常であることがわかります。案の定、それはキャッシュです。

バグ修正:

このバグは、最新リビジョンを更新し、Baidu Cloud プラグインがデータベースを更新するキャッシュを更新するコードを追加することで解決できます。

リーリー

---

以下は WordPress のキャッシュとグローバル変数に関する追加の知識です:

(1) wp_cache_flush() 関数はどのように定義されていますか?

リーリー

それでは、$wp_objecg_cache->flush() 関数はどのように定義されているのか尋ねてください。

リーリー

この $this->キャッシュは初期化時にどのように割り当てられますか?あるいはクラス内でどのように定義されているのでしょうか?

リーリー

$this->cache は配列であり、wp_cache_flush() はこの配列を空の配列に割り当てるだけです。

(2) 次に、WP_Object_Cache によってキャッシュされるデータは何ですか?どのようにキャッシュされるのでしょうか?

まず、cache.php ファイルのヘッダー コメントのガイドラインに従い (コメントがある方が良いです)、公式ドキュメントの手順を確認してください:

WP_Object_Cacheは、複雑なデータベースクエリの結果など、再生成に計算コストがかかるデータをキャッシュするためのWordPressのクラスです。オブジェクトキャッシュはwp-includes/cache.php.

で定義されます。

プラグインを作成するときは、コード内でクラスを直接使用せず、以下にリストされている wp_cache 関数を使用してください.

デフォルトでは、オブジェクト キャッシュは非永続的です。これは、キャッシュに保存されたデータは、リクエストの間のみメモリ内に存在し、永続的なキャッシュをインストールしない限り、ページの読み込み中に永続的に保存されないことを意味します。キャッシュプラグイン

上の赤いテキストに注意してください。これは基本的に次のことを意味します: WP_Object_Cache キャッシュは、データベース クエリの結果など、コンピューティング リソースを消費するデータを繰り返し生成する必要があります。デフォルトでは、WP_Object_Cache は特定のリクエストの間のみ存在します (リクエストが終了すると、キャッシュも削除されます)。これらのキャッシュをページ間 (クロスリクエスト) で使用したい場合は、次のようにする必要があります。持続可能なキャッシュ プラグインをインストールします。

(3) Web サイトにはどのようなキャッシュ プラグインがインストールされていますか? memecached がありますが、プラグイン リストに見つかりません。

その後、Baidu で検索して、WordPress で Memcached を有効にする方法に関するこの記事を見つけ、wp-content ディレクトリにインストールされていることがわかりました。

WordPressについてはまだまだ学ぶことがたくさんあるようです。

参考：

WordPress公式リファレンスマニュアル

WordPress で Memcached を有効にする方法