Ktai Entryタグの投稿
2008-07-21
なんとか Ktai Style と Ktai Entry の WordPress 2.6 対応強化 (wp-content ディレクトリーの移設対応) を行ないました。Lightweight Google Maps (LWGM) および Weather Journal も同様の改良を行なっていますが、他に改善したい点があるため、リリースはもう少しお待ちください。
LWGM の方は、固定ページに登録した位置情報が大きい地図ページに出ないという問題・同じ地点に複数マーカーがつくと下にあるマーカーがクリックできない問題に手をつけようとしています。Weather Journal の方は、WordPress 2.5 以降で天気を未設定のまま投稿しようとすると、WordPress の JavaScript の所為で、直前に投稿した他の日の天気が入ってしまう問題が見つかっています。そういう挙動をキャンセルするよう JavaScript を追加する必要がありますが、どう実装すればいいか悩んでいるところです。
また、今回サボりましたが、管理機構の SSL 対応により、クッキーの扱いが変わったり、プラグインのありかを示す URL を取得する新しい API が用意されたりしたので、これを使うようプラグインを修正することも考えています。特に、Ktai Style は管理機能があるため対応は必須です。しかし、日本の携帯電話は、SSL でクッキーを使うときの挙動があやしいため、うまく実装できるかどうかは不安です……。
WordPress 2.6 対応とは違いますが、Ktai Location で「同一地点であるかの判定」が厳しすぎることが分かりました。7月19日に京都駅についたレポートで、本文に埋め込まれた GPS情報URL による位置情報と、写真の EXIF に埋め込まれた位置情報の両方の地図が出てしまっています。Ktai Location が抽出した位置情報が微妙に異なっていたわけですが、これは au 端末が写真の位置情報をもとに作った GPS情報URL の精度が悪いのか、Ktai Location の内部処理が悪くて計算結果が間違っているのか、要調査ですね。
[追記] LWGM ですが、バージョン 1.40 のベータ版を出しました。
WordPress 用メール投稿プラグイン「Ktai Entry」のバージョン 0.8.6 をリリースいたします。変更点は以下の通りです。
- 外部メールボックスの読み出しを「しない」に設定したとき、または、読み出し時間間隔を経過していない場合は、外部メールボックスを読み出すトリガーとなるスタイルシート表示を行わないようにしました。
- WordPress 2.6 以降で、wp-content/ ディレクトリーもしくは wp-content/plugins/ ディレクトリーを移設した場合に対応しました。ktai_entry/wp-load.php の書き換えが必要です。
- 本文が同じ内容を投稿しようとするときの重複チェックを強化しました。
- 添付画像がサーバーに保存できなかったときのエラー処理を改善しました。
- プラグインを停止したとき、POP3 サーバーのパスワードのみ初期化するようにしました。(従来はすべての設定を初期化していました)
- 次の独自フィルターフックを追加しました: post_category, post_keywords, image_rotate, post_name, post_date
今回は WordPress 2.6 対応の強化および、独自フィルターフックの追加です。WordPress 2.6 の新機能のうち、管理機構の SSL 化には対応していません (外部メールボックスを「すぐ読み出す」などが動かなさそう)。独自フィルターフックは、「VGA 以上の画像でも強制的に縦向きにしたい」という相談があったため、フィルター関数を書けば可能になるようにしたものです。ただし、このフィルター関数はテストしてないので動かなかったらごめんなさい 
2008-07-09
Masayan さんところで「もし今、WordPressのプラグインフォルダに10個のプラグインしか追加できないとしたら、最低限何を入れますか?」というトラックバック企画が行なわれていますので、乗っかってみましょう。当サイトで使用しているプラグインは、一応自己紹介に書いてある通りならば「7つ」(Akismet, WP-Multibyte-Patch 除く) ですが、実はそこから微妙に増えていて12個になってしまいました。
ということで、そこから優先度の低いものを削ると以下の通りでしょうか。
- Edit Comments XT (Wöhrer 氏作)
- 非ログインユーザーがコメント投稿した場合でも、ユーザー自身が一定時間だけ編集可能とする。
- EventCal (自作・未公開)
- サイドバーのイベントカレンダー。日本の祝日対応
- Force Wave Dash (自作)
- Windows 環境で入力した「全角チルダ」を「波ダッシュ」に補正。
- Ktai Entry (自作)
- メール投稿 (モブログ)
- Ktai Style (自作)
- 携帯電話対応。軽量なページを表示・簡易的な管理機構を提供。
- Reject Short Comments (自作)
- スパムコメント／トラックバック対策。短いコメントやトラックバックを拒否。
- Weather Journal (自作)
- 日付の横に自分で入力したお天気を表示。
- WordPress.com Stats (Skelton 氏作)
- WordPress.com のアクセス統計機能を自分のサイトで使えるようにする。
- Ynet Permalink (自作・未公開)
- 以前の Yuriko.Net におけるパーマリンク体系 (/arc/YYYY/mm/ddX) を実現。
旅行記の方では位置情報と地図が必須なので、拙作のKtai Location および Lightweight Google Maps が追加になります。そのかわり、Ynet Permalink は不要になるため、都合10個に収まります。
同じく拙作の JSeries Notifier ですが、自サイトでは常に最新版が入っているので使う必要がありません。また、サイドバーでアーカイブを年ごとに折り畳む処理は、テーマファイルの functions.php で自作関数 (未公開) を書いているため「プラグインの個数」の制約にはひっかかりません スパム軽減プラグインのNonce! Please も、テーマの comments.php や functions.php に押し込めることが可能なので、必須プラグインからは外れます。
WordPress 導入以前の Yuriko.Net の見た目・機能を実現するための自作単機能プラグインが多く、他人さんのプラグインは非常に少ないです。これは、「既存のプラグインに満足できるものが少ない」「他人のコードが信用できない」「自分でプラグインを作るのが楽しい」という理由もあります。2番目の理由は結構深刻で、セキュリティーに無頓着なプラグインが結構あるんですよね……。以前、旅行記では「Plug’n Play Google Map」を使っていましたが、地点数が増えると PHP メモリー不足になることと、XSS 脆弱性があったことで、「人気があるプラグインでも信用ならない」ことが分かってしまいました。作者にセキュリティーホールを報告しても梨のつぶてで、これが「自分でプラグインを書く」きっかけとなり、他人のプラグインを入れるのは慎重になりました。
といっても、Edit Comments XT, WordPress.com Stats については、セキュリティーホールがないことのチェックはサボっていますが
[追記] しまった。旅行記の方では「Change Thumbnail Max Side Length」も必須でした (WordPress コア改造で逃げるか、テーマの functions.php に移設する手もありますが)。そのままだと11個になってしまうので、WordPress.com Stats を外すことにします。
2008-07-04
拙作プラグインの WordPress 2.6 対応をすすめていますが、他にも考慮しなければならない新機能がありました。それは WP_CONTENT_DIR, WP_PLUGIN_DIR 定数の設定です。Codex にある WordPress 2.6 の新機能では特に説明がありませんが、これらはおそらく「wp-content/ ディレクトリーや plugins ディレクトリーをデフォルト以外に設定するための仕掛け」だと思われます。
Ktai Style, Ktai Entry では、プラグインの持つリソース (言語リソースや携帯テーマなど) のアクセスのため、PLUGINDIR 定数をもとにパスを変数に保存しています。このため、WordPress 2.6 対応させるためには、WP_PLUGIN_DIR 定数を基準にしなければなりません。他の置き場所に変更した場合に不具合が出ないようにするためにも、対応は必須ですね。
Ktai Style 1.41, Ktai Entry 0.86 はほぼリリースできる状態になっていたのですが、これらの対応をするために、もうちょっと手直しが必要なようです。
[追記] 「What Plugin Coders Must Know About WordPress 2.6」のコメント欄で指摘されていますが、プラグインディレクトリーを移設する機能を使うと、wp-config.php を include するスクリプトが正常動作しなくなりそうです。wp-load.php への相対パスが一意に決まらないため、「WordPress 2.6 対応」で書いたように dirname(dirname(dirname(dirname(__FILE__)))); で WordPress ルートに辿り付くとは限らないためです。うーん。これは困りました。事実上、「プラグインディレクトリーを移設する機能は使いものにならない」ということですよね。
チケット #6938 にコメントしました。Ryan さんからは wp-content/wp-load.php を提案されたものの、それに対する反対意見も出ていて、対応策はどうなるやら。とりあえず、WP_PLUGIN_DIR 定数の設定機能は使用禁止という制限をつけざるを得ないようです。
2008-06-25
WordPress 2.6 ベータ版が出た (tai さんの記事) とのことで、拙作プラグインも対応を図ることにしました。一番影響が大きいのは「wp-config.php をウェブルート以外の場所に置く機能」ですね。Ktai Style や Ktai Entry は、wp-config.php を require するという挙動をしている箇所がいくつかあるので、これらを新設の wp-load.php の require に変更しなければなりません。WordPress 2.5.1 以前との互換性を考えると、以下のように wp-load.php の存在をチェックして require するファイルを変更すればいいでしょう (ABSPATH のチェックはお好みで)。
if (defined('ABSPATH')) {
$path = ABSPATH;
} else {
$path = dirname(dirname(dirname(dirname(__FILE__)))) . '/';
}
if (file_exists($path . 'wp-load.php')) {
require_once $path . 'wp-load.php';
} else {
require_once $path . 'wp-config.php';
}
他の方が作られている携帯閲覧プラグイン、メール投稿ツールも、wp-config.php を include/require している箇所があるため対応は必須ですね。ただし、wp-config.php を従来と同じ箇所に置く場合はそのままで動いてしまいます。とはいえ、「セキュリティーのため、wp-config.php を移設することが好ましい」という設置指南がされることもありそうですから、その場合は対応していないプラグイン・ツールは「WordPress 2.6 非対応」となりそうです……。
[追記]「セキュリティにより重きを置くためにリモートパブリッシングを無効にできる機能」は、XML-RPC や Atom API を停止するだけで、wp-mail.php を停止するものではないようです。これも停止しないと片手落ちだと思うので、さっそく trac に提案かな〰。どうせ提案するなら「wp-mail.php 経由の POP3 サーバー DoS アタックを防止する機能」「wp-mail.php の日本語対応」もパッチ送付したいところです。
[さらに追記] wp-config.php を include しているプラグインは、「Lightweight google Maps」も該当でした (Ajax で非同期にアクセスする locations.php にある)。最近アップデートしてないので新機能も盛り込んでのリリースをしましょうか? hiromasa さん作の「wp-otenki」も該当しますので、ひさびさのアップデートがされることでしょう
[またまた追記] 「WP_CONTENT_DIR, WP_PLUGIN_DIR 定数への対応を行なって気がつきましたが、この定数を変更してプラグインディレクトリーを変更すると、上記の wp-load.php 読み込みが正常動作しなくなります!! wp-load.php への相対パスが一意に決まらないためです。うーん。どうしましょう。
2008-06-17
WordPress 用メール投稿プラグイン「Ktai Entry」のバージョン 0.8.5 をリリースいたします。変更点は以下の通りです。
- 外部メールボックスを読み出すトリガーを、スタイルシートの呼出しに変更しました。これにより、JavaScript オフの設定がされたブラウザーによる閲覧でもメール読み込みが行なわれます。
- 同じ時刻の投稿があれば重複としてエラーにする確認を、DATE コマンドで添付画像の撮影日時を投稿日時に指定した場合でも行うようにしました。
- 同じ内容の投稿がある場合、重複とみなしてエラーとするようにしました。
- デフォルトの投稿スラッグが、時分秒を繋いだ6ケタの数字にならず、固定の文字列「003328」になってしまうバグを修正しました。(Ktai Entry 0.8.4 のみ存在するバグ)
- Windows サーバーで運営していて、かつ、プラグインのフォルダー名を ktai_entry 以外に変更しているとき、正常に動作しない不具合を修正しました。
- GD が組み込まれていない PHP で稼動させたとき異常終了していましたが、添付画像ファイルを無視して投稿処理がされるようにしました。
- WordPress MU で使用した場合、管理パネルの「メール投稿」でメールサーバーの設定をできるようにしました。通常の WordPress の場合は従来通り、「投稿設定」→「メールでの投稿」にて設定してください。ただし、添付画像の投稿にはうまく対応していないかもしれません。(Ktai Entry 0.8.4 で作り込んだつもりでしたが動作していなかった)
今回は投稿スラッグが固定の文字列になってしまうバグの修正および、重複投稿チェックの強化、外部メールボックスの読み出しトリガーの変更を行なっています。最後のものはちょっとチャレンジングな変更かもしれません。JavaScript オフの環境でも動作する反面、スタイルシートの呼び出しをきっかけとしているため、ブラウザーのキャッシュに入りやすい (==何回も実行されない可能性がある) という欠点があります。手元では問題なく動作していますが、環境によってはうまくメール取り込みが行なわれないかもしれません。
機能自体の強化ではありませんが、附属ドキュメントに「メール投稿されたら管理者にメールが届くようにしたい」というカスタマイズを掲載しました。作者としてはそういう機能の必然性を感じないため本体に取り込む予定はありませんが、必要な方はカスタマイズを行なってみてください。
今回は変更点やカスタマイズについて慎重にテストを行なっているので、たぶん問題なく動作するはずです。
2008-06-14
本日の、東京地下鉄副都心線初乗りレポートを実施していて、Ktai Entry および Ktai Location にバグがあることが判明しました。申し訳ありません。
Ktai Entry の方は、投稿スラッグが時分秒を繋げた6ケタの数字にならず「003328」という固定の数字になってしまうというものです。複数回投稿すると、追番がついて「003328-2」などとなります。Ktai Location の方は、Yahoo! 地図情報の緯度・経度が小数点フォーマットの場合に認識されないというものです。どちらも以前は正常動作していたもので、機能アップやバグフィックスした際にエンバグしてしまったものです。非常に情けない……。
投稿スラッグについては、テスト時に見落してました。今日は1日で何通も投稿したため、スラッグが変だぞと一発で分かったのですが、テストは1通しかしてなかったので、一見問題ないように見えたのでした。
Yahoo! の方は、以前から存在する dms2deg() 関数にあったバグが、今回発覚したというものです。この関数は、度分秒フォーマットを小数点フォーマットに変換するものですが、小数点フォーマットを与えた場合はそのまま戻ってくるという仕様のはずでした。そのため、Yahoo! 地図情報では、度分秒フォーマットか小数点フォーマットかを気にせずにどちらの場合でも関数を通せばよいはずでした。しかし、実際にはバグのため小数点フォーマットを与えると false が戻ってしまったのです。他の地図 URL の場合は、「必ず度分秒フォーマットが来る」ことが決まっているのでバグが露呈しなかったのです。とはいえ、ソースコードをよく見たら一発で分かる類いのものです。ソースコードレビューがおざなりになっていたわけですね……。
これらの不具合は近日中に直して修正版を出したいと思います。なんか、最近はエンバグすることが多くて迷惑をおかけしています。もうちょっと品質保証体制を整えないといけませんね。
[追記 2008-06-15] Ktai Location は修正版を出しました。Ktai Entry は他に直したいところがあるため、もうしばらくお待ちください。
[追記 2008-06-18] Ktai Entry の修正版も出しました。今回のバグ以外にも気になる点が多かったため、だいぶいじっています。かなり安定しているはずです。
2008-06-05
WordPress 用メール投稿プラグイン「Ktai Entry」のバージョン 0.8.4 をリリースいたします。変更点は以下の通りです。
- 投稿日時を指定できるようにしました。日時を直接指定する方法と、添付する画像の撮影日時を投稿日時にする指定方法の2種類に対応しています。
- 添付ファイルの MIME タイプと拡張子の対応を確認し、一致しない場合は画像を保存しないようにしました。(気休め程度のセキュリティー確認)
- WordPress MU で使用した場合、管理パネルの「メール投稿」でメールサーバーの設定をできるようにしました。通常の WordPress の場合は従来通り、「投稿設定」→「メールでの投稿」にて設定してください。
今回は投稿日時指定コマンドの追加と、WordPress MU でのメールサーバー設定フィールドの追加です。個人的には、単純な日時指定コマンドは不要と思っていましたが、「添付写真の撮影日時を投稿日時にする」機能をつけたかったため、オマケとして単純な日時指定もできるようにしました。「撮影日時を投稿日時とする」アイディアはいずみちゃんから頂きました。ありがとうございます。ただし、シャープ製ソフトバンク端末のように EXIF がつかない場合や、画像回転コマンドを併用した場合 (EXIF が落ちるため) は使えません。後者については今後改善する予定です。
WordPress MU 対応は 0.8.3 リリースでは見送ったのですが、今回「MU のときだけ設定フィールドを出す」という方向で実装しました。通常 WordPress でもメールサーバー設定フィールドを独自に持つのもよさそうなのですが、「同じような設定項目が複数ある」のはよくないと考えました。wp-mail 起動問題については、WordPress コアを改修してもらう方向で直せばいいと思いますし。
2008-05-25
きょうリリースした Ktai Entry 0.8.3 ですが、実は Mail_mimeDecode.php の内部関数 (コメントで @access private と書いてある関数) を外から使うという凶悪な実装になっています。あまり行儀のよいスタイルとは言えないので、早めに修正したいところです。
で、それだけ修正しても仕方ないので、投稿日時の指定機能を付けることにしました。DATE: 2008-05-25 19:39 などと書けば、その日時になるという仕組みで、実装はとても簡単です。未来の日付にすると、WordPress コアの機能で自動的に予約投稿にもなります。
ただ、それだけ実装してもまるで芸がないので、「写真を添付したときは、写真の撮影日時を投稿日時とする」オプションを盛り込む予定です (「DATE: 1」と書いたら1枚目の写真の日付とする etc)。これは、旅のリアルタイムレポートでは絶大な効果がありまして、「写真を撮って文章を書いているうちに圏外になってしまった」とき、事後送信しても撮影した時刻が投稿日時となるため、記録という意味では正確なウェブログになります。この手法は、いずみちゃんの「Feel Fine!」で実践でされているものです (P BLOG + オリジナルの投稿スクリプトという構成)。
Ktai Entry の処理では、まずマルチパートを解析し (画像はまだオンメモリー)、次に本文だけ投稿処理をして、それから写真を保存して公開します。exif_read_data() は画像がファイルじゃないと使えないので、EXIF の日時は本文投稿時点では読めません。日時は後で読む必要があって、ちょっとややこしい処理になりそうです。
なんとか実装してみて、CVS に放り込んであります。テスト完了したら 0.8.4 としてリリースですね。
WordPress 用メール投稿プラグイン「Ktai Entry」のバージョン 0.8.3 をリリースいたします。変更点は以下の通りです。
- 各社装飾メール (デコメ／デコレーションメール等) を送信した場合、同じテキストが重複しないようにしました。装飾をそのまま反映する機能は未実装です。
- ログ機構が吐くメッセージを日本語化しやすいように、po ファイルにログ用文字列を含めました。デフォルトでは、文字化けを防ぐために英語メッセージのままです。日本語化は各自で行なってください。
- From フィールドに MIME エンコードされた日本語を含む場合でも正しくメールアドレスを検出するようにしました。従来、1バイト目もしくは2バイト目に < や > を含む場合 (「ぜ」「下」「次」など) では漢字部分をメールアドレスとして判断してしまっていました。
- 日本語名の添付ファイルを正しく検出するようにしました。ただし、保存時は日本語部分を削除したファイル名となります。すべて日本語部分のときは、ランダムな英数字をファイル名とします。
(以下、技術的な難し〰い話)
今回はバグフィックスのみです。「From に漢字を使っていると投稿できない」というバグに対応するため、MIME ヘッダをデコードしないことにしました。From, To, Cc フィールドからメールアドレスを抽出する処理は、正規表現ではなく RFC2822 に準拠した方式にしているのですが、従来、MIME B デコードしてから処理していたため、日本語部分にメールアドレスっぽい文字列があると抽出に失敗していました。MIME デコードしない状態で抽出すれば OK です。正規表現でメールアドレスを探す場合、”Ikeda,Yuriko”@example.com だとか、@ の前後に空白がある (yuriko @ example.com) とかでうまく抽出できないという問題がありますが、独自方式にも落とし穴がありました……。
日本語ファイル名ですが、Ktai Entry は「携帯電話から投稿する」ことを主眼にしていたので、ファイル名は英数字記号だけと想定していました。しかし、PC からメール送信する場合は日本語があり得るので、今回対応を図りました。そうなると、RFC2231 に対応しなければなりませんよね
既存ツールでは、MobG だけが RFC2231 準拠の日本語ファイル名を認識できます。さすがですね (でも、ソースに「RFC2331」と書いてあるのはご愛嬌)。wp-mb_mail は、RFC 非準拠の MIME B エンコードだけ対応、wpmob は日本語ファイル名を認識できません。まあ、「携帯電話から投稿」という意味では、あまり問題ではないでしょう。
なお、WordPress MU でメールサーバーの設定が入力できない件の対応は見送りました。「MU だけフィールドを増やす」手が楽ですが、それならすべての WordPress で設定フィールドをつけてもよさそうです。で、そうなると、wp-mail.php 起動の根本対策として、メールサーバー設定カラム名称を独自のものに変更することが可能になってしまいます。こうするとセキュリティーが非常にアップして魅力的なのですが、似た設定項目が複数あるとややこしいのではないかと気にもしています。そのへんの検討が進んでないので、見送り、としました。
2008-05-17
Ktai Entry と Ktai Location を併用すると、Invalid な XHTML 出力になってしまうことが分かりました。例えば、「今度は入場時タッチ不良でエラー」という記事を Markup Validation Service で検査させてみると、「p 要素が始まってないのに終了タグがある」などのエラーになります。
これは、Ktai Entry の投稿テンプレートと、Ktai Location が位置情報 URL を div 要素で囲む処理の相性が悪く、WordPress の XHTML 整形処理が正しく機能しなくなってしまうためです。投稿テンプレートは以下のように本文を p 要素で囲むようにしています。
<div class="photo">{images}</div>
<p>{text}</p>
<div class="photo-end"> </div>
で、本文に位置情報 URL があると、Ktai Location は locationurl というクラスで div ブロック化します。
<div class="photo">(画像)</div>
<p>(本文)
<div class="locationurl">(位置情報URL)</div>
</p>
<div class="photo-end"> </div>
これを WordPress は以下のように整形してしまいます。本文の直後に p 要素の閉じタグを入れるのです。このため、最初にあった p 要素閉じタグが浮いてしまうわけです。
<div class="photo">(画像)</div>
<p>(本文)</p>
<div class=”locationurl”>(位置情報URL)</div>
</p>
<div class=”photo-end”> </div>
けっきょくのところ、p 要素の中に div 要素を入れてしまうのが不正なので、これは Ktai Location の処理が悪いわけですね。もしくは、Ktai Entry のテンプレートを変更して、本文を p 要素で囲まないようにしても OK です。wp-mta が生成する XHTML はそうなっていました。しかし、この場合、縦横の写真が混ざったときのレンダリングが変になってしまうため、Ktai Entry では本文を p で囲む処理としました。
つまり、Ktai Location の div 要素囲み処理を改善して、p 要素の外に出してやればいいわけです。どうせ class=”locationurl の部分は CSS で display:none となるので、位置をずらしても問題ありません。これは Ktai Location のバグフィックスとしたいと思います。現在のバージョンが 0.99 なので、ついに 1.00 とするか、0.991 と逃げるか……。
[追記] バージョンは 0.991 として、CVS に改良版をコミットしました。手元のテストでは動作良好ですが、これから生田緑地ばら苑見学で実テストする予定です。
[さらに追記] 実地テストはダメでした。今度は div 要素に </p> が入ってしまっていました。地図 URL として認識する部分に HTML タグ要素が入らないように修正してコミットしました。
2008-05-11
WordPress 用メール投稿プラグイン「Ktai Entry」のバージョン 0.8.2 をリリースいたします。変更点は以下の通りです。
- ドキュメントに Gmail および Yahoo! メールでの設定方法を記載しました。
- ドコモ端末から Gmail, au one メール、Yahoo! メールに送信した場合に、iモード絵文字を認識するようにしました。
- ソフトバンク 3G 端末から Yahoo! メールに送信した場合に、ソフトバンク絵文字を認識するようにしました。
今回は絵文字対応の強化です。実は従来バージョンでも SSL が使えることが判明したため、Gmail での iモード絵文字対応を行ない、さらに頑張って Yahoo! メールでの iモード絵文字／ソフトバンク絵文字に対応しました。au one メールはテストしていませんが、Gmail と同じインフラなので大丈夫でしょう。Yahoo! メールにおける絵文字 JIS コードは、実機から全絵文字を送信して調査しました;-) Vodafone マークの絵文字などは未調査です (Vodafone 時代の 3G 端末を持っている人がいれば協力お願いします!!)
これで、絵文字対応はほぼ完成と言えます。イー・モバイルが対応していませんが、インターネットに出ていく時点で「?」に変換されているため、キャリア側の機能アップを待つしかありません。
あとは、デコメ等の装飾メールに対応すること、コマンドでカテゴリーやタグ一覧を返送できる仕組みを作ること、Ktai Style で下書きを作って電話機に送信し、Ktai Entry 用の投稿メールを作れるようにすること (==既存の下書きを投稿メールで上書きする機能) あたりの対応でしょうか。Ktai Entry は MobG のような投稿作成ウィザードを持ちませんが、それは Ktai Style と連携すれば似た機能が作れると考えています。
2008-05-10
WordPress メール投稿プラグイン「Ktai Entry」のテスト版を配布します。
- デフォルトでログ機能が有効です。
- ドコモから Gmail に送った iモード絵文字を認識するようにしました。
ドコモ端末をお持ちの方はぜひお試し頂けると幸いです。デフォルトでログ機構が有効なので、その点にはご注意ください。そのまま放置すると logs/error.log が巨大になって不具合が起きる可能性があります。
なんと、Ktai Entry は SSL に対応していました。すなわち Gmail が使えるということです。ただし、PHP 自体が openssl 対応と設定されている必要があります。Gmail を使うには、「メールでの投稿」を以下のように設定すれば OK です。ログイン名は「@gmail.com」が必要です。APOP のチェックは外してください。
- メールサーバー
- ssl://pop.gmail.com
- ポート
- 995
- ログイン名
- example@gmail.com
- パスワード
- (パスワード)
Gmail 側でも、POP アクセスを設定しておきます。新しく Gmail アカウントを取らず、既存アドレスと兼用するときは、「今後受信するメールで POP を有効にする」にしてください。
そして、Gmail は postfix 流の拡張アドレスが使えるので、適当なランダム文字列 ramdomを追加した「example +random@gmail.com」が有効です。誰にも推測できない文字列を使って「example+9bf809b25bc76b2e@gmail.com」などのアドレスを作り、これを投稿受付アドレスとすれば安全です。この場合、Ktai Entry オプションの「投稿用メールアドレス」にこのアドレスを記入すれば、通常の Gmail アドレス (example@gmail.com など) に送られたアドレスは無視されます。
ただ、Gmail の POP は通常の POP サーバーと違って仕様が特殊で、DELE コマンドを発行しても削除されないなど、挙動がちょっと違います。なので、通常のメールアカウントと併用するのは避けた方が無難です。新たに Gmail アカウントを取るのがおすすめです。
[追記] iモードから絵文字つきメールを Gmail に送信すると、題名・本文ともに Shift_JIS で送信していました。ということは WILLCOM と同じコードが使えるので、コピペして iモード絵文字対応を作り込みました。とりあえず仮版を CVS に上げましたので、興味ある方は使ってみてください。
WordPress 用メール投稿プラグイン「Ktai Entry」のバージョン 0.8.1 をリリースいたします。変更点は以下の通りです。
- 投稿ステータスの指定に PRIVATE (未公開) を指定できるようにしました。
- 外部メールボックスを読み出すトリガーを、init フックから wp_head フックに変更して、より確実にメッセージ取り込み処理を行えるようにしました。
- Basic 認証、Digest 認証で保護しているウェブログでも、自動的に外部メールボックスを読みに行けるようにしました。
- APOP ではなく POP を利用している場合、メールボックスに新着メールがなくても「サーバーエラー」(Bad Gateway) として処理していた不具合を修正しました。
- 投稿タイトルが文字化けしにくいよう、文字コードの検出を厳密にしました。
- 附属ドキュメントの「LightBox 用に、rel=”lightbox”属性を追加する」のコードがバグっていたのを修正しました。(画像つきメールを送信しても、投稿にはテキストしか反映されない不具合の原因)
今回は主にバグフィックスです。うまくメールが取り込まれない問題に対処するため、定期的に外部メールボックスを読みに行く仕組みを根本的に変更して、wp-shot に近い方向にしました。このため、メールボックスを読みに行くタイミングにはまると、画面表示が遅くなります。
また、0.8.0 では画像が出ないという問題が多発しましたが、これはカスタマイズ用サンプルコードにバグがあったのが原因で、Ktai Entry 本体の問題ではありませんでした。0.7.1 でも発生するはずですが、わざわざ戻して「発生するか確認」された方はいないようでした (追記: yutaka さんとこでは 0.7.1 に戻すと OK だったようです。うーん謎)。おそらく、0.8.0 にアップグレードしたと同時にカスタマイズを入れた人がほとんどだったのでしょう。ある意味ドキュメントのバグと言えます。
今回はテスト版を出したりして、多くの方のご協力を仰いでいます。まことにありがとうございます。だいぶ安定するようになっていますが、まだまだなところがありますので、今後もよろしくお願いします。
次はいよいよ SSL 対応して Gmail をサポートすることとします。そうなれば、ドコモ、ソフトバンクでも絵文字対応できるかもしれないので、調査してみます。それから、デコメ対応を試みますが、実はデコメ対応端末はドコモ、ソフトバンクしか持ってないので、au, WILLCOM 対応はかなり後回しになるでしょう。(防水、Bluetooth、電子コンパス対応でデコレーションメール対応端末はまだ存在しないので機種変更できず、対応はかなり先になりそう……)
![[パンチ]](/wp-content/plugins/ktai_style/pics/SA/punch.gif)
![[COOL]](/wp-content/plugins/ktai_style/pics/SA/eyeglass.gif)
![[目]](/wp-content/plugins/ktai_style/pics/SA/eye.gif)
![[クリップ]](/wp-content/plugins/ktai_style/pics/SA/clip.gif)
![[雪]](/wp-content/plugins/ktai_style/pics/SA/snow.gif)
![[チューリップ]](/wp-content/plugins/ktai_style/pics/SA/tulip.gif)
