バグタグの投稿
2008-08-10
WordPress 2.6 へのアップグレードを見送っていた当サイトですが、一足飛びに、WordPress 2.6.1 ベータ版にアップグレードしました。2.6 正式版よりもバグが少ないとにらんでのことです 
しかし、困った問題が発生しました。それは、カテゴリー URL が「http://www.yuriko.net/cat/ほげほげ/」→「http://www.yuriko.net/arc/cat/ほげほげ/」に変わってしまったことです。タグ URL も同様に「arc/」がついてしまいます。これは、パーマリンク構造を「/arc/%year%/%monthnum%/%day%/%postname%/」にしているために、先頭にある「/arc/」をカテゴリー URL、タグ URL にも補完してしまっているのでしょう。この挙動は不可思議なので、元に戻してもらいたいですよね……。さっそくチケット #7490を切りましたが、2.6.1 リリースまでに直してもらえるんでしょうか……。当面は、mod_rewrite かリダイレクトで逃げるしかなさそうですが。
[追記] ウチのサイトは「URL を変えない」ことが信条なのに、ソフトウェアの都合で URL 体系を変えられたら、たまったものではありません。とりあえず、wp-includes/rewrite.php をいじって元に戻しました。
450,451c450,454
< $this->category_base = 'category';
< $this->category_structure = trailingslashit( $this->front . $this->category_base );
---
> $this->category_structure = $this->front . 'category/';
> else
> $this->category_structure = '/' . $this->category_base . '/';
> // $this->category_base = 'category';
> // $this->category_structure = trailingslashit( $this->front . $this->category_base );
469,470c472,476
< $this->tag_base = 'tag';
< $this->tag_structure = trailingslashit( $this->front . $this->tag_base );
---
> $this->tag_structure = $this->front . 'tag/';
> else
> $this->tag_structure = '/' . $this->tag_base . '/';
> // $this->tag_base = 'tag';
> // $this->tag_structure = trailingslashit( $this->front . $this->tag_base );
[追記] 2.6.1 ベータ2で直りました。パーマリンク構造が /archives/%post_id% の場合でも同じ不具合が発生しますから、わりと重度な不具合だったと言えます。
2008-07-16
先日リリースした Ktai Style 1.42 ですが、WordPress 2.6 対応が不十分だったことが分かりました。それは、複数プラグインの有効化・無効化に対応していないという問題です。Ktai Style を有効にしたとき、ログインセッション保存用のテーブルを作成し、無効にしたときテーブルを削除するのですが、複数有効化・無効化を検知していないのです。このため、Ktai Style を1つだけ無効にし、その後、他のプラグインとまとめて有効にしようとすると、携帯電話からログインできなくなってしまいます。
WP_CONTENT_DIR を移設したときの対策も思いつきましたので、それらを含めた 1.43 を WordPress 2.6 日本語版が出てからリリースすることにしましょう。Ktai Style の日本語表示は、WordPress 自体の日本語表示に一部頼っていますので、WordPress 2.6 の日本語リソースの出来具合をみないことには、Ktai Style の日本語リソースを調整できないのです……。
2008-07-08
先日リリースした Ktai Style 1.41 ですが、拙作のLightweight Google Maps (LWGM) と互換性がなく、携帯電話表示で地図が出ないという問題があることが分かりました。「mobile_same_url 用のフィルター関数を携帯テーマの functions.php に書ける」ようにするため、携帯テーマ用関数を定義する tags.php を読み込ませるタイミングを遅らせたのですが、LWGM の初期化段階で tags.php の関数を使っていたたため、結果として LWGM が Ktai Style を認識できなくなり、地図を出さなくなっていたのでした。
WordPress 2.6 対応のため LWGM のアップデートが必要だったのですが、これでは急いで直す必要があります。さほど大きい変更ではないはずなので、簡単にテストして今週中には出すようにしましょう。
[追記] バージョン 1.30 にて修正いたしました。なお、Ktai Style もバージョン 1.42 以降にアップデートすることが必要です。
2008-07-02
Ktai Style 1.41 をリリースすべくテストを重ねていますが、細かいバグが少しずつ発見されてしまい、それを修正してはまたテストする、というサイクルに陥っています……。1.3x 系統がバギーだっため、その尻拭いという状況ですね で、今日は「外部サイトのリンクをクリックしたとき、携帯サイトの検出時に不正な URL を拾ってしまう」という現象を発見しました。具体的には、「ひたちなか海浜鉄道が WordPress 採用」で、http://finder.music.coocan.jp/?p=152 へのリンクをクリックしたとき「http://finder.music.coocan.jp/?p=15224http://finder.music.coocan.jp/?p=1525」にジャンプしようとしました。http:// がダブっているのは、検出した URL が相対 URL であったとき、飛び先の URL をベースとして補完したためです。つまり、携帯サイトとして検出した URL 自体は「24http://finder.music.coocan.jp/?p=1525」でした。
これはとっても不可思議なので、redir.php をいじって実際に受信したデーターを見てみました。すると、以下のような内容だったのです。
fa
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="
9
text/html
a
; charset=
……中略……
2e
<link rel="alternate" media="handheld" href="
24
http://finder.music.coocan.jp/?p=152
5
" />
実際のデーターの前にバイト数がくっついた形式になっています。はて、PHP の fgets() はこんな形式になったっけ、と思ったのですが、よく調べると、これは HTTP のチャンク形式のデータなのでした。RFC2616に詳しく書かれていますが、とほほの WWW 入門の解説がシンプルで分かりやすいでしょう。
このサーバーはえらく細切れにデーターを返していて、肝心の rel=”altinate” media=”handheld” の URL 部分の前後でチャンクが切れてて、バイト数が挟まってしまっていたのです。その結果、「24http://finder.music.coocan.jp/?p=1525」が携帯サイトの URL であると検出していました。数回リトライしてもほぼ同じ結果です。なお、たいていのサーバーでは 1024 バイトぐらいは一括して返してくるので、こういう現象はめったに起きません。
redir.php のコードは、wp-includes/comment.php の discover_pingback_server_uri() を参考にしていますが、このコードがチャンク形式を考慮していないため、今回の現象が発生しました。対応させるためには、HTTP ヘッダで「Transfer-Encoding: chunked」の有無を確認し、あれば「バイト数・コンテンツ」のペアで受信させることが必要になります。WordPress コアの不具合なので、trac にも報告(#7224)しておきました。添付ファイルを2回送ってしまったのはちょっとしたミスです
これで、携帯サイトの検出も問題なくできるようになりました。もうちょっとテストしたいので、Ktai Style 1.41 のリリースは金曜日ぐらいかな〰。
[追記] trac のコメントで「HTTP/1.0 ならばチャンク形式がないので、リクエスト自体を HTTP/1.0 にすればよいのでは」という提案がされています。そういう手もあるかと思いますが、それでいいのかな??
2008-06-28
Ktai Style 1.30 から、「PC 版ページの URL に携帯電話でアクセスするとモバイル版ページが出るブログサービスへのリンク」は中継ページを出さないようにしましたが、この「ブログサービスの一覧」は mobile_same_url フィルターを使えば編集できます。しかし、コードの不具合で、フィルター関数を my-hacks.php に置かなければなりませんでした。当初の予定では、携帯テーマの functions.php に置いても OK のはずですが、それでは動作しないという報告を受けてしまったのです。
いろいろ調査した結果、tags.php, shrinkage.php を早い段階で require してしまっているのが原因でした。mobile_same_url フィルターの適用は、shrinkage.php が require されたタイミングです。設計上は、template_redirect アクションによって、Ktai_Style::output() メソッドが実行された時点で tags.php が require されるつもりでした。
しかし、よくコードを見てみると、admin/class.php でも tags.php を require していました。admin/class.php は ktai_style.php の初期化段階 (WordPress コアによってプラグインがロードされた時点) で require しているため、結果として、shrinkage.php がプラグイン初期化時点で読まれていることになります。この時点では、携帯テーマの functions.php はまだ読まれていないので、当然そこにフィルター関数を書いても無効なわけです。
うーん。これは require じゃなくて require_once と書いていたために発見できなかった現象ですね。安易に once を使ったらダメということかもしれません……。この問題の調査には、報告者さんにもご協力頂きました。大変ありがとうございます。
当初の仕様と違っているため、admin/class.php で tags.php を取り込むのはやめて、class.php では tags.php にある関数群を使わないようにします。また、require_once は極力 require に直しましょう。それらの変更を行なった Ktai Style 1.41 は土日に出す予定ですが、テストがなかなか進んでいません。7月上旬まで伸びてしまうかも。
2008-06-24
先日リリースした Ktai Style 1.40 で、「小さい画像が表示されない」「画像をリンク表示しているとき (mova, ソフトバンク PDC 等) で、PNG, GIF 画像のサムネールへのリンクが Not Found になる」というバグがあることが分かりました。前者は 1.35 でエンバグしたもの、後者は当初からあるバグ (実装の不良) です。
前者は、小さい画像の場合、携帯向けサムネール (長辺が 96 ピクセル) を作らず元画像をそのまま表示させるようにするはずが、1.35 あたりで「改良」したときに「元画像をそのまま表示する場合」を考慮してなくて、不正な処理になっていました。
後者は、「PNG, GIF 自動切り替え機能」の設計不良で、元画像および携帯向けサムネールしか PNG, GIF 画像の切り替えにしか対応していなかったのが原因です。中サイズおよび PC 向けサムネールは対象になっていないのです。3G 端末など、画像をインライン表示しているときは携帯向けサムネールを表示するので問題ないのですが、mova, ソフトバンク PDC では PC 向けサムネールにリンクするので、これらの画像に対しても GIF→PNG ないし PNG→GIF の変換を用意してやらないといけなかったわけです。テストサイトおよびわたしの実運用サイトはほとんどが JPEG 画像なので、なかなか発見できなかった現象です……。
前者のバグはすぐ修正できるのですが、後者はちょっと時間がかかりそうです。今週中には修正版をリリースしたいと思いますので、しばらくお待ちください。
[追記] とりあえず、両方修正したバージョンを CVS リポジトリーに置きました。今回のバグが気になる人は、shrinkage.php を入れ換えてください。
2008-06-18
申し訳ないことに、しばらくの間、当サイトで携帯からコメント投稿できない状態でした。これは、携帯対応プラグイン Ktai Style のバグで、スパム対策の自作プラグインがうまく動作しなかったのが原因です。スパム対策プラグインのテストは行なっていましたが、PC 閲覧と携帯閲覧で動作が違ってくるとは予想できず、携帯からのテストは省略していました……。Ktai Style 1.40 にてバグ修正しましたので、問題なくコメントできるようになりました。
旅行記にも同じ不具合がありました。そちらはコメントがしばらくついてなかったので、「どこかバグっているのかも」とは思っていましたが、きちんと調査しませんでした。ご迷惑をおかけいたしました。スパム対策の副作用と言えるわけで、なかなか難しいですね……。
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-09
なんと、Ktai Style 1.35 および 1.50-test3 には「携帯からコメントできない」(白紙画面ないし PHP エラー表示) という問題があることが分かりました。利用者の方が見つけられたのですが、できれば、当サイトないしはWP 日本語フォーラムで報告して頂けるとありがたかったです。
原因は、comments-post.php の 93 行目で、$allowedposts 配列に絵文字用属性の localsrc, alt を追加する部分です。従来は単に代入していたのですが、それだとすでに $allowedtags['img'] に配列が存在した場合に消えてしまうので、+= 演算子によって「追加」にしました。しかし、これは PHP の構文エラーになっていたのでした。
この問題はテスト時に発見していたので、リリース時は元通り代入に戻したつもりでしたが、直っていなかったようです……。1.35 と 1.50 の2系統あって、comments-post.php を揃えるとき古いファイルで新しいのを上書きしてしまったのかもしれません。「直したはずなのに直ってない」というのは一番嫌ですね……。
これは重大な問題なので、Ktai Style 1.36 および 1.50-test4 は、できれば今日中に出したいと思います。
Ktai Style を WordPress 2.3 以降で使った場合、「標準 URL (canonical URL) としてリダイレクトする飛び先が不正になる」というバグがあることが分かりました。例えば、http://example.jp/?cat=3 をリクエストしたら http://example.jp/category/living/ に正規化される場合、Ktai Style では http://example.jp/://example.jp/category/living/ となってしまいます。当然 Not Found になります。
WordPress はパーマリンクを設定していてもクエリー文字列を使った URL でアクセスできるため、WordPress 2.3 以降、パーマリンクを使った URL を強制させるべく、非標準の URL を (クエリー文字列を使った URL など) を標準 URL (パーマリンクを使った URL など) にリダイレクトする仕組みがあります。例えば、living カテゴリー (ID:3) のアーカイブは http://example.jp/category/living/ が標準 URL となります。クエリー文字列を使った http://example.jp/?cat=3 でもアクセスできますが、これは前者の URL にリダイレクトされるのです。しかし、Ktai Style では、「URL のホスト部分を削除する」というフィルターを入れているため、その副作用で「スキーム文字列」 (http の部分) だけ落ちてしまい、「://example.jp/category/living/」がリダイレクト先になってしまいます。この場合、カレント URL が補われて「http://example.jp/://example.jp/category/living/」にジャンプしようとするわけです。
「MT4i みたいに、カテゴリーのポップアップメニュー (プルダウンメニュー) を付けたい」というカスタマイズをした場合、プルダウンで選んだカテゴリーアーカイブは非標準の URL のため、標準 URL にリダイレクトされます。カスタマイズを紹介した時点では問題なく動作していたはずなので、それ以後のバージョンアップで不具合が出てしまったようです。
一応対策コードを作ってみましたが、redirect_canonical() が出力するリダイレクト先 URL が不正だったら直すという対処療法的なものです。これだと、対策コードが想定しない不正な URL が来た場合はそのまま通ってしまいます。といって、「URL のホスト部分を削除するフィルター」をなくしてしまうとパケット削減効果が落ちてしまいます。「携帯電話では非標準の URL がリクエストされることは少ない」と考えて、この対策で進めましょうか。
さほど致命的なバグだとは思っていませんので、これの修正を入れたバージョン 1.36 のリリースは、しばらくお待ちください。6月中には出す予定です。Ktai Style 1.50-test3 の方は、redportal テーマに PHP 構文エラーがあるという致命的なバグがあるので、早期に修正版を出したいのですが、他にも調整したい部分がありますので、数日お待ちください。
2008-05-25
まことに申し訳ないことに、5月20日ごろから当サイトおよび旅行記でコメントができない状態になっていました。スパム対策のため、「コメント欄に URL しか入ってない」状態のときエラーを出すようにしたのですが、デバッグのため、正しいコメントでも exit() させていたのを除去し忘れていたのでした。携帯電話は、コメント受付処理が違うためコメント可能だったはずです。
トラックバック・ピンバックが可能だっため、気がつくのが遅れてしまいました。コメントしようとしていた方にはご不便をおかけしておりました。ごめんなさい。
なお、Reject Short Comments にもバグがあって、コメントできない状態になっていた模様です。配布ファイルを差し替えておきました。なんと、テスト方法がミスっていて、配布したファイルはテストが通っていなかった (!) のが原因でした。当サイトだけ特別に wp-comments-post.php をいじっていますが、そこで Reject Short Comments と同じ処理を入れていたため、正しく動いていると勘違いしていたためでした。
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-09
「Ktai Entry で、画像付きメールを送っても画像が出ない」バグですが、どうやら、「LightBox 用に、rel=”lightbox”属性を追加する」というカスタマイズに提示したコードがバグっていたのが原因でした。大変失礼いたしました。現在は修正しましたが、当初は以下のようになっていました。
function ke_rel_lightbox($html, $id, $size) {
if (preg_match('/rel=["\']/', $html, $match)) {
$html = str_replace($match[0], $match[0] . 'lightbox ', $html);
} elseif (! preg_match('/rel=/', $html)) {
$html = str_replace('<img ', '<img rel="lightbox"', $html);
}
}
add_filter('image_link/ktai_entry.php', 'ke_rel_lightbox', 10, 3);
これでは、返り値がないので、フィルターの結果が「空」になってしまいます。return $html; を追加すればよさそうですが、2つ目の str_replace もマズくて、これだと <img rel="lightbox"src="..... のように rel 属性と src 属性が繋がってしまって不正になり、消えてしまいます。置換文字列は '<img rel="lightbox" 'と末尾にスペースが必要です。
カスタマイズ用のコードも一通りテストはしていますが、lightbox 用コードはテストしていなかったんですよね…… (post.php で alt 属性を追加するコードをコピペしたものなので OK と判断したため)。この不具合が多くの人で発生したということは、Lightbox を使っている人が結構多いわけで、こういうフィルター関数を使わなくても付与できるように、コア機能として取り込んだ方がいいのかもしれません。
2008-05-04
会津旅行でのリアルタイムレポートを行なっていますが、メール投稿で誤記したのを訂正しようと Ktai Style での投稿編集を行ないましたが反映されていません!! 旅行記はまだ WordPress 2.3.3 なんですが、Ktai Style がバグっているようです。WordPress 2.5 だと編集機能が動くことは確認しているんですが、2.3.3 はテスト手抜きしていました……。早めに修正したいと思いますです。
[追記 208-05-05] 再度確認してみたところ、テストサイトでは WP 2.3.3 でも編集機能は正しく動作していました。旅行記で動かないのは個別事象かもしれません。とはいえ、不具合には違いないので、原因究明を行なってみます。
[さらに追記] さらに調査した結果、携帯ログインしたユーザーと異なるユーザーの投稿で編集失敗していました。タグ追加はできています。管理機能は WordPress コアの API を使っているわけですが、その API の使い方がまずいのかも。←大違いでした。同一ユーザーでも発生します。他の原因を推測していますが、それに合致する状況でも発生しない (編集できている) ことがあって、ちょっと謎です。少なくとも「WordPress 2.3.3 以前では、投稿編集／コメント編集機能は不具合がありそうなので、使わないのが無難」と言えます。(コメント編集機能は OKでした)
[追記 2008-05-06] なんと、投稿管理で「検索」機能がまるで動作してないことも判明しました。WordPress 2.5 で投稿一覧表示がされない問題に対応したとき、検索ワードでの絞り込みを作り込んでなかったようです……。なんか Ktai Style 1.3x はボロボロやな〰。1.4x 系統の開発は凍結して、しっかりバグ出しした方かも
2008-04-24
きのうリリースした Ktai Entry ですが、POP3 アクセス方式 (wp-shot スタイル) だと、カテゴリー指定や画像回転がうまくいかない可能性があります。ローカルのテストでも再現してしまいました。「ROT:L」のコマンド部分の除去はできているんですが、肝心の画像が回転されていません……。
カテゴリー指定や画像回転機能は、wp-mta のコードを流用していて、メールサーバーから Ktai Entry をキックする方式 (wp-mta スタイル) だと問題なく動作しています。
POP3 で取り込んだメッセージと、STDIN から読み込んだメッセージとで、何か違いがあるのかもしれません。どちらも改行コードは CRLF で同じはずなんですが……。
[追記 2008-04-25] POP3 の場合、改行コードが CRLF なのですが、qmail から STDIN 経由で受け取ると LF のみに変換されているようです。Ktai Entry 側で CRLF → LF 変換させた方がいいかもしれません。コードを精査すると、回転コマンドの末尾に空白が入っている場合もうまく認識されないことが判明したため、CR コード駆除と同時に対策してみます。
2008-04-12
4月以降、WordPress 日本語フォーラムが活気を帯びていて、Ktai Style に関する質問も多く出るようになってきました。拙作のプラグインが広く使われるのはうれしいことですが、バグ報告が上がってくるのは悲しいことです。
しかも、報告されたバグは「白紙ページになる」「title 要素が文字化け」という手強いもので、解明は難航しています。Ktai Style は「PHP 5.2.0 以降対応」という凶悪仕様が幸いして PHP のバージョン違いによる問題は少ないのですが、多種多様なウェブログを携帯向けに変換するという宿命で、元のコンテンツによっては不具合が出てしまいます。
現在、1.30 の不具合を修正したバージョン 1.31 を制作していますが、この2点のバグ対応を盛り込めるかどうかは微妙なところです。両者とも質問者からの追加情報待ちで、それがないと対策しようがありませんので……。
なお、バージョン 1.31 は、バグ修正以外に次の改善を予定しています。
- コメント一覧画面で、コメント投稿者の名前からサイト URL にリンク、もしくはトラックバック・ピンバック元サイト名からサイト URL にリンクするようにしました (従来はリンクせず名前だけ表示していました)。
- コメント編集画面で、個体識別番号を要求したときに取得した端末番号・USIM 番号や契約者IDが見られるようにしました (PC 向け管理パネルでは WordPress 2.5 以降に対応、携帯管理画面では WordPress 2.2 以降対応)。
- iモードID通知をオフにしている端末に対しては、端末製造番号を要求するようにしました。
1番目は、「外部リンクを全て削除」という初期仕様が、コメント一覧画面ではそのままだたったことの対応です。本文に対しては、「外部リンクを中継ページ経由のリンクに変換」と仕様変更したのに、コメント一覧画面では適用していなかったという……。
[追記] 「title 要素が文字化け」の方は、「PHP 5.1.6 で稼動させていた」のが理由でした。しかし、報告者は「Ktai Style 1.21 ならば動いていた」ということで、謎は残ります。まあでも、動作確認していないバージョンの PHP ということで、とりあえずクローズですね。
[追記 2008-04-18] 「白紙ページになる」「title 要素の文字化け」ですが、両方ともAll in ONe SEO Pack が原因っぽいです。確かに All in One SEO Pack のソースを追ってみると、白紙になるか文字化けするかの現象が発生しそうです。正直、このプラグインの実装が凶悪すぎるのですが、なんとか対策してみますか。
