WordPress Jetpack pluginを強制的に止める

非常に限定的な状況での話なのですが、とあるWordPressサーバで Jetpack プラグインが動作しなくなるということがあり相談を受けました。

動かないなら止めればいい、と思うのですが、Jetpackの管理画面も、プラグインの停止リンクも、真っ白やデザインの無いページに遷移してしまい、プラグインを止めることができません。

自分の管理下のサーバなら、直接サーバをいじればいいのですが、サーバーにログインする権限がなく、pluginフォルダを削除できません。(サーバに触れるなら、プラグインのファイルを消してしまえば終わりです) mysqlの直接アクセスも許されていないので、プラグインの利用フラグを直接オフにすることもできません。

WordPressの管理画面だけは管理権限があるので、これでなんとか止めよう、となると、管理画面からの「プラグイン」の「編集」しかありません。

jetpack/jetpack.php を単に止めただけでは、Jetpack の処理は起動しなくなりますが、Jetpack プラグインを停止・削除できないのは同じです。そこで、jetpack.php の冒頭にある要求WordPressのバージョン番号

define( ‘JETPACK__MINIMUM_WP_VERSION’, ‘4.5’ );

を、現在のWordPressバージョンより大きな数字、たとえば’10.0’とかに書き換えて保存することで、Jetpackのバージョンチェックが走り、プラグインは停止してくれました。

一旦停止状態になれば、管理画面から削除してしまうことも可能です。

ただいまブログのデザインがてきとーになっております

ここのところ当ブログのサーバーがCPU100%に張り付いて無応答になることが頻発していたので、ApacheとかPHPとかAPCとかWordPressプラグインとか、あーでもないこーでもないと色々いじっていました。

何をやっても改善しないので、ふとテーマファイルをWordPressについてきたものに変えてみると、サーバの負荷がぴたりとおさまりました。まさかテーマファイルが原因だったとは。

ということで、真の原因はまだ見てないのですが、時間が取れるまでこのテーマのままになります。

WordPressのPHP4対応が今年後半予定のWordPress3.1で打ち切りへ。PHP5.2以上への移行が必要に

PHPのオープンソースの中でもユーザーがとても多い、ブログアプリケーションのWordPressが、ついにPHP4系のサポートを止める時が来ました。

WordPress公式ブログにて発表されたのは、現行バージョン3.0の次、2010年内にリリース予定のバージョン3.1を最後にPHP4とMySQL4が対応されなくなることです。

2011年前半予定のWordPress3.2では、PHP5.2以上、MySQL5.0.15以上が必須となります。

WordPress側で取っている統計では、PHP5.1より前の古いPHPを使っているワードプレスのサイトは、すでに全体の11%にまで減っているのだとか。

僕自身はもう何年も前からPHP5しか使ってないですし、プラグイン等を書くにしても、PHP4で動くようにPHP5の便利な関数を使えないのは面倒なので、PHP5.2が強制になるのは非常にうれしいですね。

共有ホスティングなどでも最近はPHP5を提供してたり、切り替えられたりするところがほとんどだと思います。今PHP4で走らせているWordPressで、その環境が将来の3.2が動く環境かどうかを確認するプラグインHealth Checkというのも公開されました。

WordPressの管理画面から、[プラグイン]-[新規追加]-[検索]で”Health Check”と入力し、見つかったヘルスチェックプラグインをインストールします。

インストール後に有効にすると、そのタイミングで今のホスティングがWordPress3.2に対応しているかどうかが簡単に表示されます。

お使いのWordPressでこのプラグインを走らせてみて、もしチェックが失敗するようであれば、使っているサーバーのPHPやMySQLのバージョンを上げる設定ができないかを確認しておいた方が安心かもしれません。もしリクエストしてもバージョンがあがらない環境であれば、別のホスティングへブログを移すことも検討しないといけないでしょう。

AsiajinのWordPressを3.0にしたら日本語が化けるようになったので対処した

あまり類似例は無いかもしれないけど、いちおうメモ。

前提として、海外のホスティングで古いバージョンのWordPressから使っていたというのがあります。しかも、そのWordPressはホスティングサービス(Dreamhost)が用意したワンクリックインストーラーでセットアップしたものでした。つまり、WordPressの細かい設定はおまかせで立ち上げたものです。

# 英語のブログだから、おまかせでいいだろう、と判断したような記憶がうっすらと。手抜きはいかんですね。

今回WordPress3.0に上げたら、以前の記事中の日本語が化けて表示されるようになり、また編集フォームで日本語を書いたらそれもすぐ化けるようになりました。

原因は、MySQLデータベースの中のテーブルの文字エンコーディングとコレーションが、’latin1′, ‘latin1_swedish_ci’になっていたことです。これでは、データベースとやりとりする時のテキストが、西ヨーロッパ言語のアルファベットとして保存されてしまいます。

しかし、WordPress2.9.xまでは日本語も問題なく動いていました。それはなぜかというと、書き込んだ日本語をlatin1だと思い込んで格納し、ブログ記事を表示するときもlatin1のつもりで元と同じデータを表示していたため、偶然元の日本語に戻っていたからです。

WordPress3.0でどうして化けるようになったのかは追ってないですが、たぶん、エンコーディングの指定がない時にはUTF-8でDBと接続するようにされたんじゃないかと思います。その結果、latin1で入っていた日本語をUTF-8で取り出そうとして、不要な変換がかかってしまい、化けるようになった。

で、修正ですが、データを全部取り出して、テーブルのエンコーディング指定を変更し、再度そのデータを入れなおす、という方法をとりました。

まずはWordPressのバックアップを。念のためにバックアップしたファイルは別のマシンへ退避させます。ブログへのアクセスを止めるため、メンテナンスモードにします。Apacheの設定で別ページを表示するとか、メンテナンスを表示するpluginを使うとか、このへんはいろいろ。

ホスティングのサーバにログインして、データをlatin1だと思い込ませてダンプを行います。

$ mysqldump –host=(mysqlサーバ) -u user -p db_name –default-character-set=latin1 > db_name.latin1.txt

保存されたファイルを開いて、日本語部分が日本語として出ていることを確認します。ここでも化けていたら、最初の仮説(latin1として日本語を格納している)は間違っていたことになります。

ダンプされたSQLの中のテーブル定義に、たくさん’latin1’が入っていると思います。これを’utf8’に置換します。これをたとえば db_name.utf8.txt として保存

そうしたら、このファイルでもってデータベースを上書きします(mysqldumpでダンプしたSQLは、create前に今あるテーブルをdropしているので)

$ mysql –host=(mysqlサーバ) -u user -p < db_name.utf8.db これで、メンテナンスモードを解除し、日本語を含んだページを表示させてみて、文字化けしていなければ完了です。ここでも念のためにバックアップを取りました(変換直後の状態に戻す必要が出るときのため)