雑念ベース

　Amazon アソシエイト支援プラグイン AmazonLink の0.9.2 をリリースしました。今回はバグの修正のみです。ダウンロードは、いつものように WordPress Plugins/JSeries のページから。

• AmazonLink（WordPress Plugins/JSeries）

修正内容の解説

　修正したバグは、プラグインファイルを置いてあるディレクトリの名前が正しく取得できないというものです。Windows サーバーでは、そのディレクトリのフルパスとなっていました。

　0.9.1 では、AmazonLink.php の76行目に次のように記述してあります。

　これを、0.9.2 では次のように変更しました。80行目です。

　この行の処理は、自分自身（AmazonLink.php）のフルパスからディレクトリ部分を取り出し、それを階層ごとに分割した配列を取得するというものです。Linux などでは階層の区切り文字は /（スラッシュ）ですが、Windows では \（バックスラッシュ。日本語版 Windows では円マークで表示されます）です。区切り文字が正しくなかったため、分割ができていませんでした。

　対応方法として、文字を直接指定するのではなく、定数 DIRECTORY_SEPARATOR を使用するように変更をしました。この定数には実行環境に合わせて階層の区切り文字が入ります。

　ちなみに、次の行で取得した配列の最後の要素を取り出して使用しています。この値が、プラグインファイルの入っているディレクトリの名前となります。

　Google は Firefox を推奨しています。内部事情はわかりませんが、少なくとも外部からはそう見えます。Google パックという、複数のアプリケーションをセットにした製品にも、Google ツールバーセット済みの Firefox が含まれています。Firefox 愛用者にとって、比較的親しみを感じる企業といえるでしょう。

　そんな Google のサービスの1つに、Google AdSense があります。いわゆるアフィリエイトサービスで、ページにあった広告が自動的に表示されるものです。
　このサイトでも使用していますが、さきほどその中に Internet Explorer 7（以降、IE7と表記します）の広告がありました。マイクロソフトの広告かと思いきや、その広告の文章は Google が IE7 へのアップグレードを推奨するというもの。リンク先のページのアドレスのドメインも www.google.com と、Google のものになっていました。

　Google にとってマイクロソフトはライバル関係にあるわけで、塩を送りまくっているように見えます。とりあえずダウンロードページを見てみることに。クリックだと規約違反になるので、アドレスをコピーペーストしました。

　ダウンロードページは英語ページでした。広告では単に IE7 にしましょうということしか書かれていませんでしたが、そのページには「Google に最適化された IE7 にアップグレードしましょう」と書かれていました。最適化の内容は、ホームページ（スタートページのほうです）が Google になっていること、Google ツールバーがインストール済みであること、IE7 の検索窓から Google の検索ができるようになってることの3点だそうです。

　IE7 を普及させることが目的ではなく、利用者の多い IE を使って Google をもっと認知してもらうのが目的だったようです。これは、Firefox の場合にも同じことが言えそうです。

　Google の戦略は、無料サービスを広告のように使って知名度を高め、そこから有料サービスの導入につなげるというもののように思えます。以前は無料サービスばかりでやっていけるのかと思っていましたが、今はしっかりと稼いでいるようです。多数の無料サービスで消費者は喜び、そこから有料サービスを始める人によって経営者も喜ぶ。ブログなどを見た限りでは、一般従業員も楽しんでいるようです。今のところよい形になっているようですね。

　最近企業視点が多いですが意図はないです・・・。

　WordPress のアップグレードと一緒に、そのままになっていた akismet-multibyteview のアップグレードもしました。1.20 からはダッシュボードのボックス枠（名前はあるんでしょうか。hook が activity_box_end なので、アクティビティーボックス？）にマルチバイトスパムの数が表示されるようになってさらに便利に。

　サイト内トラックバックが捕獲されてしまったので早速リンクから一覧に飛ぼうとしたのですが、File Not Found になってしまいました。ブラウザのアドレス覧を見ると http://edit-comments.php?page=akismet-admin&multibyte=true となっています。ソースコードでもやはりおかしなことに。

　こういうのを見るとついつい調べてみたくなります。早速ハックです。

ソースを見る

　何はともあれ、ソースコードを見ます。該当の処理は akismet-multibyteview.php の関数 akismet_stats_mbinfo が行っています。1.21 では139行目から始まっていて、目的の場所は156行目です。

　clean_url() という関数が使われています。URL として正しくなるように修正をするもので、WordPress ME2.1.3では wp-includes/formatting.php で次のように定義されていました。

　1078行目で、:// を含まなく / で始まっていなくて半角英数字＋拡張子 php になっていない場合に http:// をつけるという処理をしています。

　そして、引数の文字列に含まれる変数 $this->akismet_admin_uri は、同じファイルの62行目で次のように定義されています。

　さて、ここで関数に渡される引数を確認してみます。変数が展開されると、引数は edit-comments.php?page=akismet-admin&multibyte=true となります。拡張子は php ですが、半角英数のファイル名ではありません。ハイフン（-）が入ってしまっています。そのため、clean_url() は http:// をつけてしまっていました。

　初めは akismet-multibyteview のバグだと思い解析をしていましたが、実は WordPress 側のバグでした。2.2.1 のコードでは次のように修正されています。

　作者のひろまささんはすでに2.3系になっていますので気が付かなかったのかもしれません。

修正

　コアファイルのほうを修正してもいいのですが、影響範囲が少ないプラグインのほうを直してしまいます。固定アドレスなので、関数の処理は必要ないと判断。156行目を次のように変更しました。ついでに & を文字参照にしてあります。やらなくても大丈夫ですが、気分的に。

　これによってリンク先が正しくなり、マルチバイトスパムの一覧に飛ぶことができるようになりました。

　アップグレードによって動かなくなった WP Paginate の替わりとして、WP-PageNavi を入れてみました。WordPress 2.1 に対応した 2.20 を使用しました。

　インストールはいつものようにアップロードして管理画面から有効にするだけ。注意したいのは、アップロード先のフォルダ名が固定であること。プログラム内でファイルパスがハードコーディングされているため、もともとのフォルダ名から変えてしまうといろいろと問題がおきそうです。

　管理画面が日本語じゃないといやだという方は、Masayanさんによる日本語リソースをどうぞ。

• WP-PageNavi 日本語版（MMRT daily life）

　WordPress が 2.1 の場合は対応したファイルを、2.2 の場合は wp-pagenavi-ja.mo を WP-PageNavi のフォルダに入れます。

　先日行われた WordPress 交流会で質問してみたところ大丈夫そうだったので、2.0.11 から 2.1.3 にアップグレードしました。いくつか注意点があったのでまとめておきます。

　サーバーは XREA Free の s229。現時点でPHP が 5.1.5、MySQL が 5.1.11、PHP へのメモリ最大割り当て（memory_limit）は90MBです。

　なお、例によって作業は自己責任でお願いします。

MySQL データの変更

　現在使用しているサーバーでは phpMyAdmin による MySQL へのアクセスができます。これを使って WordPress のテーブルを見ると、すべての日本語が文字化けしてしまっていました。おそらく、UTF-8 の文字データを latin1（設定などによって変わります）に変換して処理していたのが原因と思われます。通常の使用では問題ありませんでしたが、気持ちが悪いのでアップグレードの前に修正をしました。

　念のため、作業前には phpMyAdmin で全テーブルの完全バックアップをしておきます。後述する文字化けについては目を瞑ります。元に戻せればいいのです。

　phpMyAdmin から単純にエクスポートすると、テーブル内の文字化けがそのままになってしまいます。プラグイン WordPress Database Backup を使ってバックアップをすると、文字化けのない SQL ファイルが得られます。ファイルには DROP TABLE 処理も含まれるため、これを phpMyAdmin でインポートすることによって、UTF-8 データに置き換えることができます。

アップグレード

　基本的には、ファイルをすべて上書きしてアップグレードプログラムを走らせるだけです。配布場所からフルセットのファイル（今回の場合は wordpress-me213.zip）をダウンロードしてきて解凍。その中にある readme.html の説明に従います。

　アップグレードだけでなく新規インストールの場合にも言えることなのですが、MySQL のバージョンが 4.1.x か 5.x.x の場合は、そのままだと文字化けしたりすることがあります。デフォルトの文字コードが一致していないのが原因で、私の場合は真っ白になってしまいました。

　対策として、使用する文字コードを指定してやります。私は UTF-8 なので、それに合わせます。

　まず、WordPressのインストール先/wp-includes/wp-db.php を開きます。そして、次のコードを探してください。

　見つけたら、そのすぐ上に次のコードを追加します。これによって、MySQL に文字コードは UTF-8 を使うということを指示することができます。EUC-JP にしたい場合は、utf8 の替わりに ujis とします。

　なお、私の場合はアップグレード前の 2.0.x でもにも同じことをやってありました。WordPress のバージョンよりも、MySQL のバージョンに依存する問題です。WordPress 2.2 ではこの対策が標準で入るようになったため、2.2.x にアップグレードする場合はこの作業は必要ないと思います。

アップグレード後の修正

カテゴリ名

　リンク（2.1 ではブログロール）のカテゴリの扱いが変更になっています。2.0 では wp_linkcategories という専用のテーブルが使われていましたが、2.1 ではエントリーカテゴリーと同じテーブルでカテゴリを管理し、wp_link2cat で関連付けするようになっています。
　この変更をするときに問題があるようで、カテゴリ名が ??? になっていました。一般ページのサイドメニューで使われるので、カテゴリ管理ページから修正しておきます。

テーマ

　テーマのファイルで wp_list_cats() を使っていて、なおかつサブカテゴリの表示をしないようににしている場合は注意が必要です。処理が変更されていて、サブカテゴリが表示されてしまいます。現時点では対策がありませんので、とりあえずコメントアウトしておきました。

　この問題については、ローカル環境でアップグレードに挑んだときの記事で詳しく書いています。動作しないプラグインなどについても書いてありますので、アップグレードを行おうとしている方はそちらもご覧ください。

その他

　とりあえず一通り触ってみてますが、今のところこれといって問題はないようです。拙作プラグインの AmazonLink もちゃんと動いていますし、新機能のオートセーブ機能も動いています。

　このまましばらく使用を続けてみても問題がなければ、テーマの変更と問わせて 2.2 系へのアップグレードを行いたいと思っています。