MovableTypeにSmartPhoneOptionを追加するとき

  • 投稿日:
  • by
  • カテゴリ:

さて、何が原因でどっぱまったのか、顛末を書こうと思う。全く同じ環境のヒトがそういるわけでもないから、全く同じに全てにはまっているとは限らないし、かつ、ここに書かれていることだけで全てが解決するわけでもないだろうが、何かの参考程度にはなると思う。

まず、SmartPhoneOptionを追加するには、MovableTypeのサイトにある説明に従って、モジュールをMTのディレクトリに配置するところから始まる。ここで、配置を間違えたり、必要なパーミッションの設定をおこなっていないなどは論外である。そんなことで失敗しただけならば、未明までどっぱまったりはしないのだ。

導入したら、早速、PCとスマホの両方から管理画面へとアクセスしてみる。が、ここで、スマホは、何をやっても、「リダイレクトが多すぎる」といって蹴られてしまう。おかしい、なんでそんな……と、思ったら何のことはない。iMTという、iPhone向けの、管理画面ツールを導入してあったために、SmartPhoneOptionとかち合ってしまったのだ。プラグインの一覧からiMTを無効化して、ここはクリア。

さて、次は、ブログのSmartBlog化である。すぱっと、まずは、テーマのなかからSmartBlogを選んで適用してしまう。が、これは、ほとんど不可逆の作業なので、DBをまるごとバックアップしておくなどして、非常事態に備えるべきである。テンプレートやウィジェットはバックアップは作ってくれるが、これを戻す方法は、手でちまちまとやるしかないのだ。ならば、DBをずとんと、戻してしまう方が早いだろう。

最初の注意点は、ブログの公開先が、ユーザディレクトリなどで、Apacheのaliasを使っている場合だ。これは、先のドキュメントにも注意点として書かれている。テンプレートのうち、.mtview.phpを生成するものに、

$alias_name = '/~araki/rakugaki/';
$alias_path = '/home/araki/public_html/blogs/rakugaki';

のように、$alias_nameと$alias_pathとを設定してやる必要があるのだ。これ、必ず、テンプレートの方にやること。ブログディレクトリの.mtview.phpを直接いじっても、上書きされてしまうので。

他にも、サーバによっては、.htaccessにかける項目が制限されていたり、さらには、Apacheですらなかったりする場合もアリ、このあたりも、確認しておく点だ。うちの場合は、そっちの問題はなかったが。

さて、再構築して、ブログを見てみようと思ったら、500エラーが返ってくるじゃないですか。が、error_logには何も出ていない。寡黙な漢、PHPの仕業に違いない。

一般的に、PHPは、エラーを表示するようにしておくと、多様な実装とアプリケーションから、様々な、エラー未満の警告を出しまくってくれる。デバッグしているときにはありがたいが、やれ、この表現はdeplicatedだとか、一々表示されると、ウェブアプリとしては具合が悪い。画面のレイアウトが崩れてしまうからだ、致命的でもないエラー未満のあれこれで。

なので、多くの場合PHPはエラーがあっても、黙って勝手に終了してしまうようになっている。結果、エラーレポートはどこかへと葬り去られてしまうわけだ。

これを、エラーを表示するようにしてもらわなければ、何が起きているのかさえわからないので、エラーの表示が出るようにする。.htaccessにフラグを足すか、php.iniを改変して、apacheをbounce(mod_phpはphp.iniを変更しても読み直さない。apacheごと再起動するしかない。)してやると、エラーがブラウザ上にべろりと出てくるようになる。

.htaccess:
php_flag display_error On

php.ini:
display_error = On

早速走らせたら、reCaptchaが、BaseCaptchaProviderがない、と文句をいっている。中をみてみると、class reCaptchaは、BaseCpatchaProviderを継承して宣言されている。なるほど、どうやら、reCaptchaのDynamicHTML.pack環境下での動作に問題があるようだ。つまり、reCaptchaプラグインを使ってないヒトは、ここではまることはないわけだし、ググっても誰も困ってないところを見ると、今時、コメントの認証にreCaptchaなど使わないのかも知れない。何しろ、どこへ行こうとしているのか、時を経るごとに、reCapchaは、字が読めなくなってきてしまっているから。

reCaptchaを使うことの是非はさておき、放置しておくのも何だし、今更、reCaptchaをナシにして、スパムコメントの嵐に沈むのはごめん被るので、なんとか問題を解決する方向で考える。

とりあえず、当ブログに導入されているreCaptchaは0.10という大昔のもの。とりあえず、最新版とおぼしき0.24へとアップグレードしてみる。が、reCaptchaの設定が、システムダッシュボードから、各ブログのダッシュボード内へと移動した以外、大きな変化はなく、同じエラーが出続けるばかりである。

と、なれば、もう、これは、Hackしか手はないのである。そもそも、BaseCaptchaProviderはどこにあるべきなのか。init.reCaptcha.phpを見れば、外から読んでいるのは、require_once("captcha_lib.php");の一つだけだ。ならば、ここになければならない。が、<MTdir>/php/lib/captcha_lib.phpのどこを探っても出てこない。MT-5.12-jaだからか、と、MT-5.11-jaからMT-5.0-jaまでたぐってみたが、どこにもない。

もしや、と思って、4.xまでさかのぼると、MT-4.x時代には確かに、captcha_lib.phpにBaseCaptchaProviderというクラスが存在していた。実体を持たない、Virtual classとして、定義されていて、CAPTCHAの実装ごとに、これを継承して実装するようになっていたようだ。

が、MT-5になったときに、Virtual classのBaseCaptchaProviderは廃止され、代わりに、メソッドとして、CaptchaProviderが定義されるようになっていた。従って、MT-5環境下で、DynamicHTML.packとreCaptchaを使う場合には、init.reCaptcha.phpを次のように修正する必要がある。

- class reCaptcha extends BaseCaptchaProvider {
+ class reCaptcha implements CaptchaProvider {

これは、DynamicHTML.pack環境下で利用する場合のみの問題で、静的なHTMLしか使っていない場合には、PHPモジュールは呼び出されないので、この問題は顕在化しない。要するに、そういう組み合わせで使っているヒトはいない、と、そういうことなのだろう。

とにかく、上記の修正を施すと、ようやく、ブログが表示されるようになった。が、今度は、ブラウザがUTF-8ではなく、EUC-JPとして処理しようとしてしまい、文字が化け化けになってしまった。

手で、ブラウザのエンコーディングを指定してやればきちんと表示されるが、EUC-JPから、毎回直すのはとても面倒くさいしかっこわるいし、ただでさえ希少な読者が更に減少してしまいかねない。

一応、meta タグでUTF-8がcharsetとして設定されているのだが、全く効いていない。となれば、これもまた、PHPのいたずらであろう。

我が家のサーバはVineLinuxで運用されている。これのphp.iniは、デフォルトの文字セットをEUC-JPにしている。明らかにこれが、ブラウザにEUC-JPだと勘違いさせる原因だろう。

php.iniをがさっと書き換えてしまうのも手なのだが、他にも、既に動いているphpのスクリプトもあり、これらに妙な影響を与えられても困るので、ここは、テンプレートに再び手を入れて .htaccessで設定を上書きすることにする。

php_flag default_charset UTF-8
php_flag mbstring.language Japanese
php_flag mbstring.internal_encoding UTF-8
php_flag mbstring.http_input auto
php_flag mbstring.http_output pass
php_flag mbstring.encoding_translation Off

全てが必要ではないかも知れないが、念のため書いておいた。まあ、最低限、default_charsetは必要だと思われる。mbstring.internal_encodingもあった方がいいかもしれない。まあ、よくわからなかったら、全部書いてみて、試してみればよかろう!

と、ようやく、表示もぴしっと決まって、ブログのカスタマイズへと進めることになったわけだ。まとめると、

  • reCaptchaにはバグがある。
  • PHPの文字セットには気をつけろ。

と、いうことになる。毎度毎度だが、本当に、環境によって、思いも寄らぬ、誰も知らない問題に直面するものだ。それほど特殊な環境だと思っていないのだけれど、特にMovableTypeでは、バージョンアップごとに巻き込まれるので、世間一般の想定とは、うちの環境というのはちょっと違うのだろう。

なので、ここに書かれたことは、多分、ほとんどの場合には役にも立たないものなのだろうけれど、それでも、困っている誰かの役に立ってくれれば、睡眠時間と引き替えに、ドツボにはまった甲斐もあろうというものである。