JetpackとWordPress.comが連携できない場合の対処法

2017年7月11日2020年2月3日

この記事を読むのに必要な時間は約 10 分です。

久々にJetpackを使ってみた

このサイトはしばらくJetpackなしで運用していたんですが、サイトの停止を通知してくれるJetpackモニターを利用したかったのと、Wordpress.comアプリの使い勝手を試したかったので久々に導入しました。

そしたら、なにやらエラーが

状況としては、

• JetpackからのWordpress.comとの連携は成功する
• 統計情報は表示される
• ただし、設定の変更が行えない
• サイト情報を見ると赤いビックリマークがついてる状態
• ビックリマークをクリックすると「このサイトにアクセスできません。」と表示される。
• エラーコードは-32601

まさにこちらの記事と同じ状況。

「初動調査」としてあげられていることはすでにやっていたので、まさに同じだと思い、書かれているように非SSL化ののち再びSSL化してみた。 だがしかし、結果はNGでした。 困った挙句、JetpackのKnown issuesなるものを見たところ、

“W3 Total Cache"の文字が飛び込んできました。 そこで、「あ、これだな。」と。

原因はおそらくキャッシュ系プラグインの残骸

ここ数日、このサイトの速度を上げたい一心で、W3 Total Cacheを含め様々なプラグインを試していたのでした。

それらは試したのち効果が目立つほどではなく、またサイトの表示が真っ白になったりなど不具合が続出したため削除しましたが、どこかしらにその残骸が残っていて悪さをしているに違いない。

そのどこかしらといえば、まあデータベースですよね。

かといって、ファイルの削除や設定ファイルの修正程度ならまだしも、データベース操作は少なくとも私には難易度が高すぎるので、ここはひとつ、DBを初期化したのちコンテンツをインポートすることで、余計なものを綺麗さっぱり消し去ろうと決めたのでした。

となると、当然ながらDBのエクスポート、インポートをするのは意味がありません。ゴミデータを残したままのDBを作り直すだけになってしまうので。

そこで、Wordpressのエクスポート・インポート機能を用いることにしました。

まずこの機能の予備知識として、記事は画像付きで復旧できるものの、メディアライブラリが空になってしまうという情報を得ていたので、これの復旧はサイト表示の復旧の後で行う前提で作業を始めました。

サイトの表示をまず戻せれば、中の人の問題であるライブラリの復旧などはゆっくりやれば良いわけですから。

 

ということで手順です。

下準備

UpdraftPlus Backupでバックアップ

やはり、何かするときは必ずバックアップですね。

WP-Optimizeで最適化

データのエクスポート・インポートに極力無駄なものを含めたくなかったので、最適化してみました。

データベースの初期化

コンテンツのエクスポート

WordPressの"ツール"→"エクスポート"で、コンテンツデータを保存しました。xml形式でローカルにダウンロードされます。

その他データのバックアップ

FTPで、当該Wordpressサイトのディレクトリ名をリネームしました。(このサイトでは"monozuki.club"→"monozuki.club.bak")

データベースの削除と新規作成

レンタルサーバーの管理画面でデータベースを削除し、同じ名前で 再びデータベースを作成しました。

 Wordpressサイトの復元

その他データの復元

当該Wordpressサイトのディレクトリ名を元に戻しました。(“monozuki.club.bak"→"monozuki.club")

WordPressのセットアップ

これはおなじみの工程ですね。

コンテンツのインポート

WordPressの"ツール"→"インポート"で、先ほど保存したエクスポートデータをインポートしました。 その際、"添付ファイルをダウンロードしてインポートする"にはチェックを入れませんでした。添付ファイルはすでにサーバー上にあるのでこのチェックは不要との判断からです。

サイト復元の確認

サイトの表示を確認したところ、投稿・固定ページは正しく画像つきで表示されていました。 テーマはデフォルトの"Twenty Seventeen"になっていました。 ですが、管理画面のメディアライブラリは空っぽでした。これは想定どおり。 そしてそそくさと"Hello World!"と"サンプルページ"を削除。これでサイトの内容的にはひとまず元どおり。テーマはまだなので見た目は違いますが。

WordPress.comとの連携

Jetpackを有効化し、Wordpress.comでエラーが出ないことを確認しました。これでひと安心。

テーマなど設定の復元

テーマを元のものに再設定しました。そしてまずはキャッチフレーズ、サイトアイコンを再設定。 前に使っていたキャッチフレーズ忘れてしまったので、自サイト名のキャッシュをググって確認しました。 キャッチフレーズ、サイトアイコンとサイトタイトル画像はあらかじめ保存しておけばよかったかも。 そしてざっくりとテーマを設定しサイトの見た目をしたら、Jetpack以外のプラグインを有効化していきました。

ここでトラブル発生

ここで、記事の内容が、タイトルのみとなっており正しく表示されていないことに気づきました。一覧では正しく表示されているので発見が遅れました。

対処

記事を全て削除しゴミ箱からも削除しました。 WordPressのインポーターのバグとのことで、インポーターのファイルを

のとおり修正しました。 そして再びインポートしましたが変わらず。 そこで、振り出しに戻ってデータベースを削除→再作成しインポートしなおしたら無事に内容も表示されました。 これはレアケースだそうなので多くの場合にはこの二度手間はなさそうですが、念のためインポーターの修正はやっておいた方がよさそうです。

メディアライブラリの復元

さて、あとはのんびりとメディアライブラリの復元です。 WordPress Flash Uploaderというプラグインを使用するのが定番なのですが、今回は、以下サイトを参考に、より便利そうなMedia from ftpを使用しました。

ここで一つ注意点。 サーバ上のアップロードディレクトリが年・月フォルダになっていたのせいか、プラグインの設定にある"年月フォルダに分ける"設定のチェックしたままでは一向に動作しませんでした。要は、このチェックは外しましょう。

ライブラリの復元は簡単に自動で行われますが、時間はとてもかかります。まさにのんびり。

なんならパソコンから離れて他のことしてた方がいいかもしれません。スクリプトが走っているパソコンで他の作業をするのはなんだか怖いですしね。実際のところはどうだか知りませんが。

なお、デフォルトでは確か20画像ごとに一覧表示され、これを全チェックするなどして復元を実行させるのですが、面倒だったので一覧表示数を大幅に上げて、全て一気に実行させました。

途中に何度か止まりましたが、それでも手間はたいしたことありません。ただしあくまで時間はかかります。

サムネイルの復元

メディアライブラリが復元されたら、晴れてサムネイルの復元です。 Regenerate Thumbnailsプラグインでサムネイルを再生成しました。 これも時間はそこそこかかります。 これが終われば、晴れてサイトの見た目も中のデータもクリーンに。そしてJetpackも問題なし。

まとめ

今回のような、過去に色々試みた結果として不具合が起きていると思われる場合は、思い切ってサイトを作り直してしまうのが手っ取り早そう。要するに、

1. 記事をエクスポート
2. DBを新規作成
3. 記事をインポート

これですっきり。

以上です。

2017.7.12 追記

またエラーが出るようになりました。

• Luxeritasテーマではエラーコード -32601
• デフォルトテーマに戻すとエラーコード -32300

これはもうJetpackとWordpress.comに問題があるとしか思えない。

キリがないのでひとまず放置。-32300エラーの方は、これが出ていても必要な設定変更はできるので、あまり実害ないし。

2017.7.13 追記

上記エラーの原因と対処法をまとめました。