• labocho’s photolog

もうちょっとがんばって撮った写真(携帯電話以外で撮った写真)はflickrに置いたまま。これが200枚に達したらProアカウントにするか考えよう。

• Flickr: labocho’s Photostream

で、移行ですが、手動で1つづつ移すのは面倒なので、両サービスのAPIを利用して、flickrの特定セットの写真をtumblrに投稿するスクリプトを作成、ローカルサーバで走らせました。

自分で、しかも1回使うだけなので、使い勝手はひどいですが、参考にしたい人もいるかと思いますので、掲載しておきます。

flickr.photosets.getPhotosだとオリジナル画像のURLが取得できるのに、flickr.photos.getInfoだと取得できないのがよくわからんけど、まあ問題なし。

これをxampp上で実行して、tumblrを確認しだい、手動でflickr側の写真を削除していきました。削除は手でやったほうが安心だもんね。

その後、サブドメインの設定をドメイン管理会社の管理ページとtumblrのカスタマイズページで行い、めでたく完了。

いやしかし、API提供されてるといろいろ便利です。Webサービスを選ぶ際にはAPIやインポート/エクスポート機能をちゃんと見ておくべきですね。

参考

• Flickr Services
• API | Tumblr
• Using a custom domain name | Tumblr
• Tumblrにサブドメインを割り当ててみた | www.undakovr.com
• tumblrにfaviconをつける – 頭ん中

このブログでは、Wordpressを http://penguinlab.jp/blog にインストールし、記事単一のページのURLを http://penguinlab.jp/blog/post/(一意の記事番号、記事スラッグを利用) にするため、管理ページの「設定」-「パーマリンク設定」で、パーマリンクを post/%postname% とした。

さらに同じ設定ページでカテゴリベースとタグベースを設定した(/blog/category/(カテゴリ名) および /blog/tag/(タグ名) とした)のだが、日付別表示に関してはベースURLの設定がなく、/blog/post/2009/4 のようになってしまう。/blog/postは単一記事専用としたいので、ここは /blog/date/2009/4 のようなかたちにしたいところだ。

いろいろ調べてもいい方法がなさそうだったので、結局プラグインを作ることになった。

WordPressがURLを解決する仕組み

まずはWordpressがインストールされているディレクトリにある.htaccessを見てみよう。

# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase /blog/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /blog/index.php [L] </IfModule> # END WordPress

細かいところは違うだろうが、だいたいこのかたちになっているはずだ。5,6行目の「RewriteCond %{REQUEST_FILENAME} !-f 」「RewriteCond %{REQUEST_FILENAME} !-d 」は、リクエストされたファイル/ディレクトリがなければ、7行目の書き換えルールを適用するという意味だ。7行目は全部index.phpにアクセスさせるということを意味する。つまり、リクエストされたとこにファイルかディレクトリがればそれを返し、なければWordpressの index.phpに丸投げしている。

で、index.phpでは、リクエストされたURLを解析してindex.phpにパラメータを付けたかたちに書き換える。たとえば /blog/2009/4は/blog/index.php?year=2009&month=4 のように書き換えられ、投稿日が2009年4月の記事が表示される。試してみるとわかるが、この整形後のURLをブラウザのアドレスバー/ロケーションバーに直接入力してもアクセスできる。

URL書き換えルール

で、じゃあそのURL書き換えルール(Rewrite Rules)をどうやって設定してるかというと、(wordpressのインストールディレクトリ)/wp-include/rewrite.phpでそのルールを作っているらしい。Wordpressの管理者ページの「設定」-「パーマリンク設定」で「変更を保存」した際などにこのルールを作り直してるものと思われる。

で、いま、その整形のルールがどんな風になっているかは Internal Rewrite Viewer というプラグインを導入することでみることができる(インストール→有効化→「設定」-「パーマリンク設定」-「変更を保存」→(ブログURL)/rewritesでアクセスできる)。以下は今回の変更を加える前のURL書き換えルールの抜粋である。

Array ( [post/([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/?$] => index.php?year=$1&monthnum=$2&day=$3 [post/([0-9]{4})/([0-9]{1,2})/?$] => index.php?year=$1&monthnum=$2 [post/([0-9]{4})/?$] => index.php?year=$1 )

URL書き換えルールは連想配列で、キーが表向きのURL、値がindex.phpにパラメータが付いたかたちで定義されているのがわかる。 さてこれをどのように弄ればいいだろうか。

フィルターでURL書き換えルールを書き換える

WordPressはプラグインを使うために、フィルターという仕組みを用意している。

WordPressのソースをみると、プラグインで処理を挟みたいような部分で、apply_filtersという関数が呼ばれている。これは、プラグインがadd_filterという関数で登録した関数を呼び出してくれるものだ。

で、URL書き換えルールを作る部分にもフィルターが設定できる。今回は日付別一覧を弄りたいので、date_rewrite_rulesにフィルターを設定する(「プラグイン API/フィルターフック一覧 – WordPress Codex 日本語版」にURL書き換えのフィルターフック一覧がある)。

フィルター追加のひな形はこんな感じである。

function my_filter($arg){ $result = ""; return $result; } add_filter('date_rewrite_rules', 'my_filter');

呼び出される関数にどんな引数が渡されるかは、フィルターフックによって変わる。どんなものが渡されるかについてはあんまり情報がないので、場合によってはWordpressのソースからapply_filter呼び出してるとこを探すことになる。

date_rewrite_rulesの場合、上でInternal Rewrite Rulesプラグインで見たような、連想配列のかたちで渡される。

あとはフィルター内で好きなように書き換えて返してやればよい。今回は最初のpost/部分をdate/に書き換える。

function add_date_base($rewrite_rules){ $r = array(); while(list ($key, $val) = each($rewrite_rules)) { $r[str_replace('post/', 'date/', $key)] = $val; } return $r; } add_filter('date_rewrite_rules', 'add_date_base');

テンプレートで書き出されるリンク先の変更

これで、思い通りのURLでアクセスする方法はわかったが、まだ1つ問題がある。テンプレートで書き出されるリンクが変更前のままなのである。これもまたフィルターを設定することで解決できる。

プラグイン API/フィルターフック一覧 – WordPress Codex 日本語版にリンク関連のフィルターフック一覧がある。これらのフィルターフックは引数として、URL文字列を渡してくる(http://penguinlab.jp/blog/date/2009 のような、プロトコル名から始まる完全なかたちのURLである)。単なる文字列なので、文字列関数で適当に書き換えて返してやればOKだ。なお、日付別表示のリンクは年別、年月別、年月日別の3種あるので、すべて書き換える。

function add_date_base_link($string){ $string = str_replace('post/', 'date/', $string); return $string; } add_filter('year_link', 'add_date_base_link'); add_filter('month_link', 'add_date_base_link'); add_filter('day_link', 'add_date_base_link');

あとはこれをプラグインにするだけだ。

プラグインの作成、有効化、URL書き換えルールの再作成

WordPressプラグインの作成方法は他所にいくらでも書かれていると思うので、簡単な説明にとどめておく。

まず、さきほど書いたコードにタイトルなどのメタデータを書き加え、適当な名前で(ローカルに)保存しておく。

<?php /* Plugin Name: Add Date Base Description: Add date base Version: 1.0 Author: labocho */ function add_date_base($rewrite_rules){ $r = array(); while(list ($key, $val) = each($rewrite_rules)) { $r[str_replace('post/', 'date/', $key)] = $val; } return $r; } function add_date_base_link($string){ $string = str_replace('post/', 'date/', $string); return $string; } add_filter('year_link', 'add_date_base_link'); add_filter('month_link', 'add_date_base_link'); add_filter('day_link', 'add_date_base_link'); add_filter('date_rewrite_rules', 'add_date_base'); ?>

さらに適当な名前のディレクトリを作成し、この中にさきほど保存したファイルを移動しておく。

次に、これを (WordPressのインストールディレクトリ)/wp-content/plugins の下にディレクトリごとコピーする(あるいはディレクトリごとzipにして、管理ページからアップロードしてもよい)。

あとはWordpressの管理ページを開き「プラグイン」-「インストール済み」にさきほど作成したプラグインが表示されているので、有効化する。

無事、有効化できたら、URL書き換えルールを再作成するために、管理者ページから、「設定」-「パーマリンク設定」-「変更を保存」をクリックする。うまくいっていればこれで作業は完了である。思い通りのURLでアクセス出来るか、確認する。うまくいかない場合は、いや、うまくいった場合でもInternal Rewrite RulesでどのようにURL書き換えルールが変化したか確認しよう。

今回の変更では、上に挙げた部分が以下のように変わっていることを確認した。

Array ( [date/([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/?$] => index.php?year=$1&monthnum=$2&day=$3 [date/([0-9]{4})/([0-9]{1,2})/?$] => index.php?year=$1&monthnum=$2 [date/([0-9]{4})/?$] => index.php?year=$1 )

あとがき

このような方法で、WordpressのURLをかなり柔軟にいじれる。本来ならば、変更前のURLへのアクセスを301リダイレクトするとかも考えるべきだろうが、まあ、許してください。ほんとはこれをもっと汎用的なプラグインにしてwordpress.orgから配信できるといいんだけど、いまのところやる気が足りません。要望があれば考えます。

reCAPTCHAってなんだって人はこちらをどうぞ。

• 秋元@サイボウズラボ・プログラマー・ブログ: reCAPTCHA – キャプチャを利用した人力高性能OCR

なお、CakePHPは1.2を使ってます。

1. まずは登録

reCAPTCHAを使うにはWebサイトでアカウントを作る必要があります。

まずはhttp://recaptcha.net/へアクセスし、「USE reCAPTCHA ON YOUR SITE」へ。

「Sign up Now!」へ。

「Sign up」へ。

ユーザー名、パスワード、パスワード再入力、連絡先メールアドレス、そしてもちろんreCAPTCHAによる画像認証を入力して「Sign up Now!」へ。

次に、どのドメインでreCAPTCHAを使うかを聞いてきます。たぶんここで入れたドメイン以外からの検証リクエストは受け付けないんでしょう(少なくともlocalhostからは受付けてましたが)。

親ドメインを入れとけばサブドメインでも使えるし、一つのアカウントで複数のドメインを登録できるし、大量のドメインから使うんだったら「Enable this key on all domains (global keys)」にチェックを入れとけば、ドメインの制限は受けないようです。

入力したら「Create Key」へ。

これで登録完了です！

「Public Key」(公開鍵)と「Private Key」(秘密鍵)は実装のさいに使用します。「Public Key」(公開鍵)は別に誰に知られてもまったく問題ないですが、「Private Key」(秘密鍵)は絶対に知られないようにしましょう(でないと認証の意味ないです)。

なお、ここで表示される情報はメニューの「MY ACCOUNT」からいつでも確認できます。

2. PHP用のライブラリを用意する

メニューの「RESOURCES」に「PHP」の項目があるので、そこへ。

「Download」へ。

Google Codeに飛ぶのでこのzipをダウンロードします。

zipを展開するといくつかファイルが出てきます。

この中の「recaptchalib.php」をCakePHPの/app/vendors下に置いておきます。

3. View側の実装

View側では<form></form>の中に入るように、以下のコードを書きます。

App::import('Vendor', 'recaptchalib'); $publickey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; echo recaptcha_get_html($publickey);

1行目はさきほどコピーしたライブラリの読み込み。

2行目はreCAPTCHAのPublic Key (公開鍵)を書きます。

3行目はreCAPTCHAのウィジェットを表示します。

たったこれだけでOK!

4. Controller側の実装

Controller側では先ほどのViewのformから呼ばれるアクション内に以下のコードを書きます。

App::import('Vendor', 'recaptchalib'); $privatekey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"; $resp = recaptcha_check_answer( $privatekey, $_SERVER["REMOTE_ADDR"], $this->params['form']['recaptcha_challenge_field'], $this->params['form']['recaptcha_response_field']);

1行目はやはりライブラリの読み込み。

2行目はreCAPTCHAのPrivate Key (秘密鍵)を書きます。

3行目はユーザーが入力した文字列を検証します。

これで$resp->is_validに検証結果が入るので、あとはお好きなように。

いまCakePHPでWebアプリケーションを作ってて(趣味です)、スターレイティングを導入しようと思い、いくらか調べて、「jQuery Star Rating Plugin」が良さそうという結論に達した。

で、さっそく実装して試してみてたら、inputのnamｅがサンプルのままの「star」だと問題なく動作するんだけど、CakePHPのdata[モデル名][カラム名]の形式のnameにすると、表示もPOSTもうまくいかない。

調べてみると、jquery.rating.js は、inputのnameをもとにクラスやなんかを作るんだけど、そのさいに[ ]をエスケープしてる。

//99行目 var n = (this.name || 'unnamed-rating').replace(/\[|\]/, "_");

まずこのエスケープがまずくて、最初の一個めしか置換してくれないので、直す。

//gオプションを追加 var n = (this.name || 'unnamed-rating').replace(/\[|\]/g, "_");

で、値をPOSTするためにhiddenのinputを作ってる。

//111行目 $.rating.groups[n].valueElem = $('<input type="hidden" name="' + n + '" value=""' + (settings.readOnly ? ' disabled="disabled"' : '') + '/>');

ここはエスケープしちゃうとCakePHPで$this->dataでアクセスできないので、エスケープする前の名前にする。

//さっきのnの宣言部からエスケープ前の名前をもってくる $.rating.groups[n].valueElem = $('<input type="hidden" name="' + (this.name || 'unnamed-rating') + '" value=""' + (settings.readOnly ? ' disabled="disabled"' : '') + '/>');

これでテストしたら、表示・挙動・POSTデータいづれも問題なさそうだった。コードを熟読してないので問題あるかもだけど。

・・・とまあ、ここまで書いといて気づいたんだけど、jQuery Star Rating Plugin ってGPL(と MIT License)なんですね。フリーだと思い込んでたよ。Webアプリケーションのソース公開はセキュリティ上問題ありそうだしなあ。同じようなの作るのめんどくさいなあ・・・。Creative Commons や MIT License なんかに比べるとGPLやLGPLって制限厳しいくせに線引きがあいまいすぎて、どうも好きになれない。

解説すると長くなるので、とりあえずPHPのサンプルを各種。プログラマー各氏にはこのほうが話が早いかも。

FC2ブログの仕様上、拡張子がphpだとアップ出来ないのでtxtにしてます。

PORTAへのリクエストでは、書誌情報のスキーマがdcかdcndl_portaか選べ、そのパッキング方法をxmlとstringから選べる。はじめどれがいいかわかんなかったので、都合この組み合わせ4つのサンプルを用意した。

• スキーマ:dc パッキング:xml
  porta_dc_xml.txt
• スキーマ:dc パッキング:string
  porta_dc_string.txt
• スキーマ:dcndl_porta パッキング:xml
  porta_dcndl_xml.txt
• スキーマ:dcndl_porta パッキング:string
  porta_dcndl_string.txt

また、先日の記事の追記でも書いたけど、PHPのSimpleXMLだと名前空間の扱いがめんどくさいので、名前空間付きの要素名を適当に置換するバージョンも2つのスキーマ向けに作った。

• スキーマ:dc パッキング:xml 名前空間付きの要素名を置換
  porta_dc_replace.txt
• スキーマ:dcndl_porta パッキング:xml 名前空間付きの要素名を置換
  porta_dcndl_replace.txt

結局、最後のやつが一番使いやすい気がします。

あと、おまけ。

• 最後のやつの出力サンプル
  porta_dcndl_replace.html

にしても、dc:identifierの種類が属性を参照しないとわからんとか、全角英数字を使ってるとか、複数の著者名と役割表示が1つの文字列にまとめられてるとか、Amazonに比べると扱いにくいこと扱いにくいこと。既存の目録規則やDublin Coreにとらわれずに、もっとまともな構造のデータで出力してくれると嬉しいんだけどなあ。

いま、蔵書管理のためのWebサービス（SocialtunesやLibraryThingみたいなやつだ）を試作してて、書誌情報をどこから取ろうかと考えた結果、amazonを主に、NDL(国立国会図書館)を補助として使うことに決めた。

NDLだけでは最新の図書の書誌情報が得られず、amazonには古い図書の情報が少ないというのが主な理由だ（ほかにもNDLにはシリーズやNDCなんかの情報があったり、書誌情報の信頼性・正確性が高いというのもある）。

もちろんWebcat/Webcat Plusも考えたが、APIとして公開しているものがなく、HTMLからの抽出は、処理の重さや信頼性、あとマナー的にもどうなのということで断念。はやくAPI作ってくださいな・・・。

WorldCatやLCも視野に入れたけど、労力の割にそれほどメリットもないので、今回は無視。NDLがWorldCatに情報提供してれば使ったかもなのになあ。

で、amazonのAPI(Amazon Associates Web Service)は超有名なだけあって、簡単に使えた。

PHPのサンプル探してたら、こちらのページがわかりやすかった。

• 週末プログラマのメモ帳:PHPでAmazon E-Commerce Service (ECS) 2
  ※こちらではクエリ文字列をrawurlencodeでエンコードしているが、うちの環境では必要なかった。

で、今度はNDLがやってる電子リソースポータル「PORTA」（今回はNDLの所蔵データベースしか使わないが）のAPIを使ってみた。※APIについてはPORTAの「このサイトについて」から「外部提供インタフェースについて」で見られる。なんでパーマリンクがないんじゃあ！

なんかSRU(Seach/Retrieval via URL;LCの作った検索プロトコル。URLでリクエストしてXMLでレスポンスがくる)はともかくSRW（SRUのリクエストがSOAP仕様のXMLになったやつ）の情報があまりにも少なくて、なんでSRUを採用しないのかちょっと理解に苦しむところではあるが、まあそれしかないんだから使うしか仕方ない。

で、以下のコードで、一応結果のオブジェクトは返ってくる。

<?php $client = new SoapClient("http://api.porta.ndl.go.jp/servicedp/services/SRWDp?wsdl"); $q = '(title = architecture) AND (dpid ANY "zomoku zassaku okayama")'; $req = array('version' => '1.1', 'query' => $q, 'startRecord' => '1', 'maximumRecords' => '200', 'recordPacking' => 'string', 'recordSchema' => '', 'sortKeys' => 'title,,1'); $result = $client->searchRetrieveOperation($req); print_r($result); ?>

しかし、返ってきたデータを見てみると、肝心の書誌情報が入っているrecordDataオブジェクトの中身がなぜか空。ヒット数とかはPORTAのWebで検索したときと同じなので、いいとこまでいってるとは思うんだけどなあ。

ちなみに渡すパラメータが足りないとエラー（java.lang.NullPointerException）が返ってくる。省略可能なのもあるし、仕様書で「設定されない場合」とかあるやつでも省略不能っぽいのもある。

ところで、このAPI、公開されてそこそこ日が経つけど、誰か使ってるんやろか。情報すくないんだよなあ。

ちなみに、今回、開発はWindows上でxamppを走らせてやってます。xamppはApache、PHP5、MySQLやらが一気に使えて（しかもPortable）たいへん便利。ただ、ドライブのルートに配置しないといかんという制限があるので、仮想ドライブを指定するコマンドを書いた、下記のバッチファイルを作ってxammpディレクトリと同じディレクトリに置いて、開発時に実行してます。

rem connect current directory to x: drive subst x: "%cd%" exit