WordPress上で正常に動いていたJetpackプラグインがエラーで、ある日突然、停止してしまうとどうしていいか戸惑いますよね。
当記事では、Jetpackプラグインがキャッシュにまつわるエラーで連携できなくなったときの一連のトラブルシューティングの内容を、解決に至ったもの、解決には至らなかったものを含めて、すべてご紹介したいと思います。
そのうちの一つでも、同じエラーに遭遇した方の一助となればと思っています。
サーバー移転にともなって、プラグインを無効化してしまったのが原因ですが、備忘録を兼ねて記録しています。
エラーの内容
エラーメッセージを文字おこしすると、以下になります。
The Jetpack server could not communicate with your site’s XML-RPC URL. If you have the W3 Total Cache plugin installed, deactivate W3 Total Cache, try to Connect to WordPress.com again, reactivate W3 Total Cache, then clear W3 Total Cache’s cache.
翻訳するとこんな感じです。
Jetpackサーバーは、あなたのサイトのXML-PRC URLと通信ができませんでした。プラグインのW3 Total Cacheをインストールしていたなら、それを無効化し、WordPress.comに再接続、W3 Total Cacheを再有効化し、W3 Total Cacheのキャッシュをクリアしてください。
ちなみに、W3 Total Cache とは、キャッシュを生成して表示速度を高速化するためのプラグインです (以下の動画は英語)。
きっかけ
もともと、サイトスピードが遅いことに、Page Speed Insights で気づいていました。
すぐにできる対策 (TinyPNGで画像サイズを縮小する) を行った後、ブログのホスティングサーバーをBluehostからXserverへ移行しました。(←もともと予定していた移行です)
さらに、Jetpackプラグインがサイト表示を遅くしているのでは、と勝手に信じ、Jetpackを無効化 (スピードに変化なし) し、再有効化したところで、上記のエラーが発生した、というのが事の発端です。
なお、Jetpackが復活した後に、ページスピードを確認しましたが、変化なしでした。
トラブルシューティング
ここでは実際に試したものを列挙していきます。
必ずどれかが解決に結びつくとは限りませんので、あらかじめご了承ください。
解決に至ったもの
旧ネームサーバーの設定に戻す
確実に正常に動いていたのは、旧ホスティングサーバーを使用していたときだったので、ネームサーバーの設定を戻しました。
手順は以下の通りです。
- WordPressの管理画面とは別のブラウザか端末で、サイトが正常表示することを確認する
- ドメイン画面にログインする (例：Google Domains)
- 現在のネームサーバーの設定を消す
- 旧サーバーのネームサーバーを入力する
- WHOISに旧サーバーのネームサーバーが反映されていることを確認する (ICANN | LOOKUP)
- 1. と同様に、サイトが正常に表示することを確認する
- Jetpackをインストール・有効化・Wordpressに接続 (※) し、同様のエラーが出ないことを確認する
※Wordpressへ接続しないでいたら、切断されたといったエラーが発生したため。なお、WordPressの管理画面上でWordPressに接続します。 - 1.、6.と同様に、再度、サイトが正常に表示することを確認する
- ドメイン画面にて、現在のネームサーバーの設定に戻す
- WordPressの管理画面で、エラーが出ていないことを確認する
試したものの、解決には至らなかったもの (6つ)
ここに紹介するのは、すべて成功に至らなかったものですが、他のケースで解決につながるかもしれませんので、参考にしてみてください。
1. サーバーのセキュリティ設定
エラーメッセージに “XML-RPC” とあったので、「XML-RPC API アクセス制限」と「REST API アクセス制限」をオフにしました。(現行の使用サーバーは、Xserver)
XserverでのWordPressセキュリティ設定手順はこちらです。
設定手順をよく見ると、「XML-RPC API アクセス制限」と「REST API アクセス制限」それぞれに、下記のように記載があります。Jetpackによるアクセス制限は対象外とのことなので、この対処法は関係なさそうです。
プラグイン「Jetpack by WordPress.com」によるアクセスは制限の対象外です。
WordPressセキュリティ設定 https://www.xserver.ne.jp/manual/man_server_wpsecurity.php
同様の設定が、他のサーバーにもあるようです。
ただし、お名前.comと、Heteml (ヘテムル) の説明では、「Jetpackによるアクセス制限は対象外」との記載はありませんでした。
必要に応じて問い合わせてみてください。
お名前.com
Heteml (ヘテムル)
よくある質問 > WordPress で XML-RPC を有効化したい
なお、サーバー上では上記のようになっていますが、WordPressでは、XML-PRCが有効になっています。日本語・英語両方のサイトでそう言及されています。
WordPress.com ではすべてのブログに対し XML-RPC が有効化されています。
WordPressサポートページ https://wordpress.com/ja/forums/topic/xml-rpc%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/#post-1135
XML-RPC is enabled by default on all WordPress.com sites
WordPressサポートページ (英語) https://wordpress.com/forums/topic/how-to-enable-remote-publishing-or-xml-rpc-option/
2. W3 Total Cacheの確認
エラーメッセージにある「W3 Total Cache」ですが、インストールしたプラグイン一覧にも存在しないし、インストールした記憶もありません。
ただ、もしかして過去にインストールして削除したかもしれない、ということで一旦インストールして有効化してみましたが、効果なしでした。
3. Jetpackの無効化とアンインストール
Jetpackそのものの問題では？と考え、一旦無効化した後、アンインストールし、再度インストールしてみましたが、同様のエラーは解決せずでした。
4. Cache (キャッシュ) 関連のプラグイン
エラーメッセージにある「W3 Total Cache」は、キャッシュに関連するプラグインなので、他のキャッシュ関連プラグインが関係しているのではと思い、インストールしてあった「WP Fastest Cache」を無効化してみました。
が、解決せずでした。
5. すべてのプラグインを無効化して、Jetpackだけ有効化
もはや、他のプラグインが影響しているのか否かが分からなくなってきました。
そこで、WordPress管理画面上で、Jetpack以外のプラグインを無効化しました。このとき、すでに無効化してあるプラグインは書き留めました。
そうしないと、プラグインの有効化をするときに、どのプラグインを除外して有効化するのか分からなくなるので。
残念ながら、この方法では解決せずでした。
ということは、他のプラグインは関係ないのかもしれません。
6. wp-content/pluginsの中にある、該当プラグインのファイルを削除
上記手順で、疑わしいプラグインは削除または無効化したものの、サーバー上に関連ファイルが残っているはずと考え、FileZillaを使用し、該当プラグイン (Jetpack、W3C Total Cache, etc.) をフォルダごと削除しました。
他のプラグインのファイルはそのまま放置です。
ただ、それでも改善せず。
解決策ではないが、問題の切り分けに役立ちそうなもの (2つ)
1. Jetpackのデバッグツール
Jetpackにはデバッグツールがあり、サイトアドレスを入力して調べることができます。
なお、私の場合は、”Something seems not working fine. (何かがおかしいようです)” といったメッセージが表示されました。
自分のサイトの問題に特化した情報ではなく、一般的なヘルプリンクしかなく、役に立ちませんでした。
2. XMLRPCファイルを確認
Jetpackのトラブルシューティングのヒントを参照し、列挙してある手順を試しました。
Jetpack または Jetpack の機能の問題にお困りですか ? その場合、ここで説明する手順に従うことで、問題を解決できる可能性があります。
トラブルシューティングのヒント https://ja.jetpack.com/support/getting-started-with-jetpack/troubleshooting-tips/
その中に、サイトのXML-PRCファイルに、空白行や余分な文字列を確認するというものがあります。
＜あなたのサイトドメイン＞/xmlrpc.php (例：example.com/xmlrpc.php) をブラウザで開いてみて、
XML-RPC server accepts POST requests only.
という行が、上下に空白行や他の文字列なく、1行だけで表示されればOKです。
私の場合は、上記が正常に表示されましたので、これは解決には至らずでしたが、XMLPRCのファイルに問題がないことを確認できたのは収穫でした。
最後の落とし穴
無事、Jetpackが正常になり一安心。
高揚した気分のまま、ブログ記事を下書き作成・保存したところ (公開していない状態)、なんと翌朝消失していました！
ブログ記事のみならず、細々とした設定変更 (メニュー変更、フッター変更) も消失していました。ほぼ、サーバー移転前の状態です。
結局、半日を調査に費やして分かったのは、旧サーバー上に保存されていたということでした。
ネームサーバー設定変更の真実
ドメインの設定画面上では、ネームサーバーの値を入力・保存して終わりではありません。
変更が完全に反映されるまでは、だいぶ (数時間～24時間) 待つ必要があります。
ほんの2-3時間では、反映が完了しておらず、旧サーバーにファイルやデータを格納している羽目になっているかもしれません。
※ネームサーバーの変更が完全に反映されるまでには一定時間必要となります。数時間～24時間程度を目安としてお待ちください。
Xserver ネームサーバーの設定 https://www.xserver.ne.jp/manual/man_domain_namesever_setting.php
記事復活として行った対処としては、以下の通りです。
- 旧サーバーの管理画面を開く
- データベースをphpMyAdminで開く
- postsフォルダから該当の記事を見つけ、編集ボタンを押してテキストを表示させる
- テキストをコピーペーストして、手作業で復元
「データベースの復元」という手段もありましたが、細々とした設定変更は手で戻してしまいましたし、一記事のために復元するとリスクの方が大きいと判断し、手作業のコピペとなりました。
まとめ
W3 Total Cacheプラグインのせいで、Jetpackサーバーが自分のサイトのXML-PRCと通信できず、WordPressとJetpackが連携できないというエラーでしたが、実際は、W3 Total Cacheプラグインは関係なく、他のキャッシュ系プラグインも関係なく、ネームサーバーを旧サーバーのものに戻したところ復活したというのが結論です。
注意点として、ネームサーバーの設定変更が完全に反映されるまでには数時間～24時間かかるので、ドメイン画面で設定が保存されても、すぐにWordPress管理画面上で記事を投稿したり、設定の変更をしたりしないようにしましょう、ということでした。
