雑念ベース

　ソーシャルブックマーク登録ボタン統合サービスの AddClips が正式版となりました。

　ソーシャルブックマークに登録するためのボタンを並べるのが流行っています。個人サイトだけでなく、Yahoo! Japan ニュースのような大手サイトでも、ボタンがずらりと並んでいるのをよく見かけます。

　このブログでもはてなブックマークのボタンを表示してたことがありましたが、ほかのにも対応する方法を探していたときに AddClips を見かけて、すぐに利用を開始しました。

　正式版となって変わった事は、オンラインRSSリーダーへの登録機能の追加と、ボタンのカスタマイズなどが出来る有料サービスである『AddClipsプレミアム』の開始です。法人で利用しているところにとっては、ボタンをサイトデザインに合わせたものに変更できるというのは大きいのではないでしょうか。カスタマイズ仕様書によると、ロゴの変更なども含めてかなり細かい部分をカスタマイズできるようです。

　また、RSSリーダーへの登録ボタンは個人でもうれしい機能です。Firefox の場合は同じような機能を標準で持っているのであまり意味がないかもしれませんが、ほかのブラウザの愛用者にとっては便利になると思います。現在このブログではポップアップウィンドウによる表示をする設定になっているのですが、RSSリーダー登録機能はマウスオーバー（ボタンにマウスカーソルを重ねる）で表示するときにしか使えないようです。先ほどのカスタマイズ仕様書を見ながら変更してみたいと思います。

　AmazonLink 2.0 で新たに必要になる素材として、商品がないときに使用する代替画像があります。”No image” だったり “Now printing” だったりしますが、商品写真の代わりとなるものです。正式な名前がなんというのかわかりませんが・・・・。

　今までのバージョンでは Amazon.co.jp が用意したものが使われるので問題なかったのですが、2.0からは自前で用意する必要があり、それなりのものが欲しいと思っていました。試行錯誤しながら作ってはみたのですが、悲しいほど出来が悪い。単純に “Image not found” とか入れてみたりしても面白くないし、Amazon.co.jp から持ってきてしまうのはいろいろ問題になりそうです。出来の悪さを認識しながらも、先日そのままサーバーにアップしてしまいました。

　そんな話を同僚に話したところ作ってもらえることに。デザインを担当しているので、私よりもはるかに上手い。喜んでお願いすることになりました。

　出来上がったのがこちら。

　お願いしたのは2つ。どんなサイトで使われるかわからないのでニュートラルな感じにして欲しいことと、主張しすぎないこと。派手すぎず地味すぎず、落ち着いた感じになりました。青みがかったグレーがお気に入りです。

　この画像は大中小の3つのサイズのうちの中です。ほかの2つも同じデザインで作っていただきました。AmazonLink 2.0 から同梱され、表示する商品に指定したサイズの画像がないときに使用されます。オプション設定で好みのものを指定できる機能をつける予定ですが、このブログではこの画像を使おうと思います。

　WordPress 用 Amazon.co.jp アソシエイト支援プラグインの AmazonLink 次期バージョンの開発をしています。このブログでも動作させています。

　開発中ということで、表示が崩れたりサイト自体が表示できないことがあるかもしれません。その場合はすぐ変更を戻したり、最悪でもプラグインをはずすことで対応しますので、しばらくすれば表示されるようになると思います。

　次期バージョンの目標は、アソシエイト広告の表示フォーマットをある程度自由に出来ること。

　現在のバージョンでは Amazon.co.jp の個別商品リンクを表示するようになっているため、自由自在にデザインを変えるということは出来ません。実際に使ってくださっていても、その点が不満であるという方が多いようです。私自身不満だったりします。

　管理画面で検索する機能を実装したことで、Amazon Associates Web Service（旧 Amazon E-Commerce Service）の使い方もかなりわかりました。データの取得に関しては大体出来ていますので、表示の仕方を煮詰めていこうと思います。今のところ、管理画面でテンプレートを入力してもらい、それを使って表示するデータを作る予定です。

　テンプレートは、多分こんな感じ。

[html]
_TITLE_

[/html]

　誰でも出来るというものではなくなってしまっていますが、個別商品リンクを使った方法も残していけばいいかなと思っています。また、いろんな人がテンプレートを公開してくれて、自分では作れないような人はそれを使ってもらうというような、コミュニティーの広がりが出来たらうれしいですね。

　バージョンナンバーですが、1.0を飛ばして2.0にするかもしれません。
　現在の最新リリース版は0.9番台ですが、これはボタンクリックでコードを挿入する機能が実装できたら1.0にしようと考えていたからです。残念ながらいまだに実現できていません。クリックされたというイベントに連動させる方法がわからないのです。実現できたときのために、1.0は空けておこうかなと。

　WordPress 管理画面のダッシュボードには、登録された WordPress サイトの記事が表示されます。そして、有志による日本語化などを行った ME 版では、本家版とは違うものが表示されていました。私は RSS リーダー代わりに記事を書かないときにも頻繁に見ていて、新しい記事が表示されるのを結構楽しみにしていました。

　ここ数日更新されなくておかしいなと思っていたのですが、ふと気がつくと、運営者からのお知らせ（これもダッシュボードに表示されます）に閉鎖するとのメッセージが。2008年3月31日で、関連コンテンツも含め閉鎖とのことでした。

　すでにいくつかのコンテンツは閉鎖されていて、WordPress サイトの記事が更新されなくなったのもそのためのようです。この機能ははてなブックマークを利用して実現しているのですが、元となるブックマークが削除されていました。新規の取得が出来ないため、現在はキャッシュとして保持されているデータが表示されているのでしょう。

　WordPress を使い始めるに当たって、WordPress Japan のサイトには非常に助けられました。あれが英語で書かれていたら、おそらくかなり苦戦したと思います。もしかしたら挫折してしまった可能性も・・・。

　改めて、WordPress Japan および、ME 版に関わった多くの方々に感謝。

　先週の記事でも書きましたように、Google AdSense の規約変更のためにプライバシーポリシーの掲載が必要となりました。いろいろと考えて自力で作ったのですが、なぜか肝心のページの公開ができません。

　公開するには、ステータスを「公開」にすればいいはずですが、私の場合はなぜかその項目が表示されていません。その部分のコードを探して確認してみることに。久しぶりのハックです。バージョンは ME2.1.3。ME2.0 からアップグレードしてあります。

解析編

　ページ編集画面のアドレスからファイルを推測したどっていくと、wp-admin/edit-page-form.php に該当箇所が見つかりました。

[php num=60]

[/php]

　63行目が公開とする項目で、62行目のところで権限の有無によって処理を分岐しているようです。管理者アカウントで作業しているので権限がないとは思えないのですが。

　今度は条件式に使われている関数 current_user_can() を調べます。まずは定義場所を見つける必要があります。ファイル群から検索という方法でもいいのですが、試しに Google で検索してみることに。キーワードは「WordPress current_user_can」。
　capabilities.php というファイルにあるという情報が見つかりました。コアファイルの置かれているところを探してみると、wp-includes/ にありました。

[php num=444]
// Capability checking wrapper around the global $current_user object.
function current_user_can($capability) {
$current_user = wp_get_current_user();

$args = array_slice(func_get_args(), 1);
$args = array_merge(array($capability), $args);

if ( empty($current_user) )
return false;

return call_user_func_array(array(&$current_user, ‘has_cap’), $args);
}
[/php]

　446行目で wp_get_current_user() が返す値を変数に入れています。変数の値を調べてみると、クラス WP_User のインスタンスが入っていました。このクラスも、capabilities.php に定義があります。長いのでコードは省略します。

　448行目の処理は、この関数の2番目以降の引数を要素として持つ配列を取得しています。今回引数は1つだけなので、当然この行の直後では $args は要素を持たない配列です。449行では配列の結合をしていて、変数 $args には array('publish_pages') に相当する値が入ります。

　454行目では、コールバック処理の結果を返しています。変数 $current_user にはクラス WP_User のインスタンスが入っていますので、コールバック関数は WP_User のメンバ関数 has_cap() と言うことになります。定義は次のようになっています。

[php num=258]
//has_cap(capability_or_role_name) or
//has_cap(‘edit_post’, post_id)
function has_cap($cap) {
if ( is_numeric($cap) )
$cap = $this->translate_level_to_cap($cap);

$args = array_slice(func_get_args(), 1);
$args = array_merge(array($cap, $this->ID), $args);
$caps = call_user_func_array(‘map_meta_cap’, $args);
// Must have ALL requested caps
$capabilities = apply_filters(‘user_has_cap’, $this->allcaps, $caps, $args);
foreach ($caps as $cap) {
//echo “Checking cap $cap
“;
if(empty($capabilities[$cap]) || !$capabilities[$cap])
return false;
}

return true;
}
[/php]

　引数 $cap には、コールバックで渡された文字列 publish_pages が入ります。数値ではないので、262行目の処理は行われません。264行目と265行目は、current_user_can() の場合と同じですね。$this->ID は、ログイン中のユーザーのID（ログインIDではなく、データベーステーブルの主キー）が入っています。

　266行目で再びコールバックです。この段階 $args には array(‘publish_pages’, ユーザーID) が入っているので、map_meta_cap('publish_pages', ユーザーID) ということをしていることになります。

　関数の定義は、285行目から442行目にかけて記述されています。これもかなり長いですが、やっていることは第一引数の値で switch 分岐処理をしているだけです。publish_pages のところはないので、default 節で次のように処理をしているだけです。

[php num=436]
default:
// If no meta caps match, return the original cap.
$caps[] = $cap;
[/php]

　そして、その戻り値は予想通り array('publish_pages') でした。

　268行目。プラグイン作成ではおなじみの、apply_filters が使われています。以前にもこの関数のハックに挑んだことがありますが、ややこしくて苦手です。面倒なので $capabilities の中身を見てみるだけに。連想配列になっていて、ユーザステータスを記録しているようです。$capabilities['publish_pages'] はありませんでした。

　269～273行目では、値がないか Not true のものが見つかったら false でリターンするという処理です。値がないので false になってしまいます。

解決編

　すっかり弱ってしまいました。散々調べ続けて、わかったのは間違いなくページを公開する権限がないことだけ。（仕組みがわかって勉強になったというのもありますけど・・・）

　方向を変えて、publish_pages について調べてみることに。「WordPress publish_pages」と検索。WordPress Japan のフォーラムに、よく似た不具合のスレッドを発見。

• アップデート後、ページの編集ができなくなりました（WordPress Japan フォーラム）

　そこからリンクされているページを見ると、データベースに記録されているシステム設定に問題がある模様。どれどれと確認してみると、$capabilities の内容によく似たデータが。そして、そこには publish_pages はありませんでした。2.0 からアップグレードするときに、スクリプトが修正してくれなかっただけなのではないでしょうか。実際、プラグインチェック用に新規インストールした 2.1 のほうでは次のような内容で、そこにはちゃんと publish_pages があります。

[code]
a:5:{s:13:"administrator";a:2:{s:4:"name";s:27:"管理人 - (Administrator)";s:12:"capabilities";a:47:{s:13:"switch_themes";b:1;s:11:"edit_themes";b:1;s:16:"activate_plugins";b:1;s:12:"edit_plugins";b:1;s:10:"edit_users";b:1;s:10:"edit_files";b:1;s:14:"manage_options";b:1;s:17:"moderate_comments";b:1;s:17:"manage_categories";b:1;s:12:"manage_links";b:1;s:12:"upload_files";b:1;s:6:"import";b:1;s:15:"unfiltered_html";b:1;s:10:"edit_posts";b:1;s:17:"edit_others_posts";b:1;s:20:"edit_published_posts";b:1;s:13:"publish_posts";b:1;s:10:"edit_pages";b:1;s:4:"read";b:1;s:8:"level_10";b:1;s:7:"level_9";b:1;s:7:"level_8";b:1;s:7:"level_7";b:1;s:7:"level_6";b:1;s:7:"level_5";b:1;s:7:"level_4";b:1;s:7:"level_3";b:1;s:7:"level_2";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:17:"edit_others_pages";b:1;s:20:"edit_published_pages";b:1;s:13:"publish_pages";b:1;s:12:"delete_pages";b:1;s:19:"delete_others_pages";b:1;s:22:"delete_published_pages";b:1;s:12:"delete_posts";b:1;s:19:"delete_others_posts";b:1;s:22:"delete_published_posts";b:1;s:20:"delete_private_posts";b:1;s:18:"edit_private_posts";b:1;s:18:"read_private_posts";b:1;s:20:"delete_private_pages";b:1;s:18:"edit_private_pages";b:1;s:18:"read_private_pages";b:1;s:12:"delete_users";b:1;s:12:"create_users";b:1;}}s:6:"editor";a:2:{s:4:"name";s:20:"編集者 - (Editor)";s:12:"capabilities";a:34:{s:17:"moderate_comments";b:1;s:17:"manage_categories";b:1;s:12:"manage_links";b:1;s:12:"upload_files";b:1;s:15:"unfiltered_html";b:1;s:10:"edit_posts";b:1;s:17:"edit_others_posts";b:1;s:20:"edit_published_posts";b:1;s:13:"publish_posts";b:1;s:10:"edit_pages";b:1;s:4:"read";b:1;s:7:"level_7";b:1;s:7:"level_6";b:1;s:7:"level_5";b:1;s:7:"level_4";b:1;s:7:"level_3";b:1;s:7:"level_2";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:17:"edit_others_pages";b:1;s:20:"edit_published_pages";b:1;s:13:"publish_pages";b:1;s:12:"delete_pages";b:1;s:19:"delete_others_pages";b:1;s:22:"delete_published_pages";b:1;s:12:"delete_posts";b:1;s:19:"delete_others_posts";b:1;s:22:"delete_published_posts";b:1;s:20:"delete_private_posts";b:1;s:18:"edit_private_posts";b:1;s:18:"read_private_posts";b:1;s:20:"delete_private_pages";b:1;s:18:"edit_private_pages";b:1;s:18:"read_private_pages";b:1;}}s:6:"author";a:2:{s:4:"name";s:20:"投稿者 - (Author)";s:12:"capabilities";a:10:{s:12:"upload_files";b:1;s:10:"edit_posts";b:1;s:20:"edit_published_posts";b:1;s:13:"publish_posts";b:1;s:4:"read";b:1;s:7:"level_2";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:12:"delete_posts";b:1;s:22:"delete_published_posts";b:1;}}s:11:"contributor";a:2:{s:4:"name";s:25:"寄稿者 - (Contributor)";s:12:"capabilities";a:5:{s:10:"edit_posts";b:1;s:4:"read";b:1;s:7:"level_1";b:1;s:7:"level_0";b:1;s:12:"delete_posts";b:1;}}s:10:"subscriber";a:2:{s:4:"name";s:24:"購読者 - (Subscriber)";s:12:"capabilities";a:2:{s:4:"read";b:1;s:7:"level_0";b:1;}}}
[/code]

　思い切ってデータを差し替えてみると、見事公開の選択肢が表示されるように。これで、やっとプライバシーポリシーの公開ができます。

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

• AmazonLink（WordPress Plugins/JSeries）

修正内容の解説

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

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

[php num=76]
$dirs = explode(‘/’, dirname(__FILE__));
[/php]

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

[php num=80]
$dirs = explode(DIRECTORY_SEPARATOR, dirname(__FILE__));
[/php]

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

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

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

　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行目です。

[php num=154]
if ( $mbs_count ) {
echo
‘

‘;
} else {
echo ‘

‘;
}
[/php]

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

[php num=1069]
function clean_url( $url, $protocols = null ) {
if (” == $url) return $url;
$url = preg_replace(‘|[^a-z0-9-~+_.?#=!&;,/:%]|i’, ”, $url);
$strip = array(‘%0d’, ‘%0a’);
$url = str_replace($strip, ”, $url);
$url = str_replace(‘;//’, ‘://’, $url);
// Append http unless a relative link starting with / or a php file.
if ( strpos($url, ‘://’) === false &&
substr( $url, 0, 1 ) != ‘/’ && !preg_match(‘/^[a-z0-9]+?\.php/i’, $url) )
$url = ‘http://’ . $url;

$url = preg_replace(‘/&([^#])(?![a-z]{2,8};)/’, ‘&$1′, $url);
if ( !is_array($protocols) )
$protocols = array(‘http’, ‘https’, ‘ftp’, ‘ftps’, ‘mailto’, ‘news’, ‘irc’, ‘gopher’, ‘nntp’, ‘feed’, ‘telnet’);
if ( wp_kses_bad_protocol( $url, $protocols ) != $url )
return ”;
return $url;
}
[/php]

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

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

[php num=62]
$this->akismet_admin_uri = ‘edit-comments.php?page=akismet-admin’;
[/php]

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

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

[php num=1083]
if ( strpos($url, ‘://’) === false &&
substr( $url, 0, 1 ) != ‘/’ && !preg_match(‘/^[a-z0-9-]+?\.php/i’, $url) )
$url = ‘http://’ . $url;
[/php]

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

修正

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

[php num=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 を開きます。そして、次のコードを探してください。

[php]
$this->select($dbname);
[/php]

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

[php]
mysql_query(”SET NAMES ‘utf8′”, $this->dbh);
[/php]

　なお、私の場合はアップグレード前の 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 系へのアップグレードを行いたいと思っています。

　予定より1週間遅れとなってしまいましたが、WordPress 用 Amazon アソシエイト支援プラグインの AmazonLink 0.9.1 をリリースしました。ダウンロードは、いつものように WordPress Plugins/JSeries の AmazonLink ページからどうぞ。

　今回の変更は、アパレル＆シューズストアでの検索対応です。使用する Amazon E-Commerce Service の API バージョンも最新の 2007-10-29 に変更されています。

　また、最近話題の WordPress 2.3.1（日本語リソース入り） で動作することを確認しました。データベース構造が変わったりしているということで心配でしたが、あっさりと動いてくれました。