Jetpackのwordpress.com連携でエラーは競合が原因だった

jetpackを利用する際に最初に一度、wordpress.comアカウントとの連携を求められます。
しかし何らかのタイミングにアカウント連携が切れ、
再度アカウント連携をしようとした際に、エラーが出てつなげない場合はありませんか？
私の場合は、プラグイン競合が原因でした。

はじめに

jetpackは非常に便利なプラグインで、正直外したくない。
しかし、jetpackは規模が大きなプラグインであることもあって、
何かと躓いたり、エラーを出力されてしまって焦るものです。
大抵は他のプラグインとの競合が原因だったりして、アップデートで回避できていますが。

さて今回出逢ったのは、jetpackというよりも、
wordpress.comアカウントとの連携でエラーが発生しました。

環境

• wordpress: WordPress 3.5.1
• Jetpack by WordPress.com: 2.3.5(当初の発生は2.5)

エラー内容

jetpackでwordpress.comアカウントとの連携をする際に、以下メッセージが表示される。

Jetpack を利用するには、サイトが公開されていて、アクセス制限がかかっていない必要があります:
site_inaccessible
エラーの詳細：
The Jetpack server was unable to communicate with your site http://algorhythnn.jp/blg/XXXXX [IXR -32300: transport error: http_request_failed transfer closed with 42 bytes remaining to read]

wordpress.comアカウント連携エラー

正直このwordpress.comとの連携については、
その連携ができない症状のみを回避したい場合は、
開発環境などで利用する為の開発モードで回避することはできます。
ローカル(localhost)環境wordpressでjetpackの有効化

ただ、開発モードでは機能がすべて有効になるわけではありませんし、
本来のエラー自体は解消されません。

経緯

経緯としては、実際に運用している当サイトにおいて、
これまで利用していた[statpress]プラグインによる統計データが
肥大化したため、プラグインの停止を行いました。

停止し、プラグインを削除した後も、wp_statpressテーブルが残ってしまっていたため、
phpMyAdminを利用してテーブルの削除を行いました。

次にwordpressのダッシュボードに戻ってみると、
wordpress.comのアカウント連携が切られてしまっていました。

再度、連携を行おうと[wordpress.comアカウントと連携]をクリックした結果が、
先ほどのエラー画面です。

正直、無関係なテーブルの削除でどうしてこのような動作をするのかが疑問です。
ただテーブル構成を大きく変更した際には再連携が必要になるという仕様なのかもしれません。

対応

私の環境の場合にはなりますが、wordpress.comのデバッガを利用して、
サイトのデバッグを行ってみましたが、
表示された内容はあまり直接的な対策ではありませんでした。

デバッグの方法は以下でご紹介しています。
wordpressがエラーとなった場合に最初に確認すべきこと

wordpress.comデバッグ結果

直接的な対策が得られなかったため、 troubleshooting guideに記述の手順を順に行いました。
「jetpack以外のプラグインをすべて無効にして確認する」とのことで、
順に確認していった結果として、原因となっているプラグインが判明しました。

私の環境では「WP HTTP Compression 1.0」プラグインが有効化されていましたが、
このプラグインが有効な状態では、wordpress.comアカウントとの連携が行えませんでした。

このことから、圧縮系のプラグインが有効な環境では、
プラグインを無効化してみることで、正しく接続が行えるかもしれません。

このプラグインを無効化し、再度連携を行うことで、
いつもの連携画面に遷移し、正しく接続を行うことができました。

wordpress連携画面による連携

wordpress.comアカウント連携

連携の完了

wordpress.comアカウント連携完了

しかし消えないDebugエラー

プラグインを無効化したことによって、
無事wordpress.comアカウントとの連携を行うことができるようになり、
取り急ぎの問題は解決され、カスタムCSSやサイト統計情報の確認が行えるようになりました。

しかし、再度Debugを確認したところ、以下のようなエラーを表示されるようになりました。

wordpress.comデバッグ結果が消えない

jetPackの[wordpress.com connect]に関連する設定かと思い、
実際にwordpress.com connectの設定を行ってみましたが、改善はされませんでした。
jetpackプラグインにWordPress.com Connectの設定を行う【作成中】

wordpress.com Connectは無関係

XML-RPC is not responding correctly ( 404 )のデバッグエラーに関連して、
正しくサイトの情報が取得できていない状態が続いているものと思いますが、
とりあえずはこの状態でも使用に耐えうるものと判断し、現時点ではこの状態で運用としました。

おそらく、これまでもずっとこのデバッグエラーは
潜在化していただけで発生していたのだと思います。

XML-RPCが正しく取得できていない原因については追って検討しようと思います。

wordpressはFree Software Foundation, Inc.によってGPL2+でライセンスされています。
Jetpack by WordPress.comはAutomattic, IncのCreative Commonsによってライセンスされています。

*本ページ内に記載されされた各社ブランド、サービス名、商標、登録商標については、
各社ブランドのロゴや商標等に関する帰属についてをご確認ください

最後までお読みいただきありがとうございました。

お勧めさせて頂きたい投稿です

• 【巧妙な仕組】Google+へAndroidの写真が勝手にアップロードされてしまう流れは設定ミスではない

• JetPackサイト統計データが消えた場合に復活する手順(してもらう)

• 【待望】WALLET ポイントがauID(au電話番号)間で相互にやりとりできるようになりました

• 禁断の機能がau公式解禁！WALLETポイントの現金化がついに開放。

• 何もしないと、auポイントが2014/05月分以降は携帯利用料から付与されなくなります

• au WALLET™カードはauを解約してもプリペイドとして使い続けられるが、有効期限には注意

• じぶん銀行が動いた！コンビニATM利用が無料・他行振込無料（回数制限なし）で使える

• 【旬】「白すぎる」と賛否両論？姫路城見るなら今秋がおすすめ！その理由は？｜castlehimeji.com

• Google+の投稿が勝手に自動でブログになっていくPluCialが便利



アイキャッチ画像に利用させて頂いております、各社ブランドのロゴやシンボルに関しては、
各社ブランドのロゴや商標等に関する帰属についてをご確認頂けますようお願い致します。

AdMax Promotion

ブログ記事のご紹介

すべて展開 | すべて省略

Rakuten Promotion

ページ

すべて展開 | すべて省略