WordPress 2.6タグの投稿

wp-content ディレクトリー移設を自動検知する
WordPress 2.6 から導入された、wp-content ディレクトリーを WordPress インストールディレクトリー以外に移設できる機能ですが、これを使った場合、Ktai Style や Ktai Entry などのプラグインはそのままでは動きません。附属ドキュメントにも書いていますが、プラグインにある wp-load.php ファイルの編集が必要です。
なぜそういう編集が必要かと言うと、Ktai Style でのコメント投稿とか、Ktai Entry での外部メールボックス確認など、プラグイン内部にあるファイルを直接起動することがあるためです。この場合、WordPress の API を使うためには、WordPress ルートディレクトリーにある wp-load.php を include
することになります。しかし、wp-content ディレクトリーを移設していると、wp-load.php への相対パスが標準とは異なるため、wp-load.php を呼び出せません。このため、プラグイン側で wp-load.php を持って、WordPress 本体の wp-load.php へのパスを手動設定してもらうことにしているのです。
しかし、WordPress を通常の方法で起動した場合 (普通にブログ閲覧した場合) は、当然ながら、wp-load.php のありかおよびプラグインの設置場所は分かります。これを、各プラグインのディレクトリーに設定ファイルとして書き出してしまえばいいのではないかと考えました。さすがに「ブログ閲覧ごと」に書き出すのは無駄なので、「プラグインを有効化したとき」ぐらいで十分だと思います。wp-load.php のありかは ABSPATH . 'wp-load.php'
で得られるので、プラグインの有効化時にはこの値を wp-load-conf.php というファイルに書き出して (check_wp_load()
メソッド)、プラグインごとの wp-load.php では、このファイルの存在を確認するという実装を試しています。
この手法を使うと、ほぼ自動で設定が可能です。ただし、プラグインのインストール時に、ディレクトリーの書き込み権限を 757 とか 777 とかにしなければならないのがネックでしょうか。チャレンジングな実装ですが、いかがなもんでしょう??
[追記] もちろん、懸念事項として、ニセの wp-load.php へのパスを wp-load-conf.php に書かれてしまう攻撃が考えられます。wp-load.php を include する前に、file_get_contents()
して中身を検査する手もありますが、それを必須にすべきかどうか、悩んでいます。

WordPress 2.6.2 リリース
WordPress 2.6.2 がリリースされました。ちょっと前に 2.6.2 ベータ1 が出てて、試さないとと思っていたんですが、時間が取れないまま正式版になってしまいました。2.6.1 で改善された「日本語タグの重複問題」ですが、ときどき重複が発生することがあったので、バグレポートしようかと思っていたのにーー。2.6.2 で発生するならば今度こそバグレポートですね。
本日 Ktai Style 1.44 のリリースをする予定でしたが、WordPress 2.6.2 での動作試験をしたいと思いますので、あした以降に延期します。Ktai Entry 0.88 は、WordPress ME 2.1.1 で不具合があるという報告があったので、それの確認 (と必要ならば修正) をしてから出す予定です (質問者は 2.6.1 にアップグレードという方法で解決されてしまいましたが、Ktai Entry としては不具合がある可能性があるんですよね)。

WordPress 2.6.1 ベータ2
WordPress 2.6.1 ベータ2 がリリースされていました (ベータ2日本語版も出てました)。「カテゴリー・タグアーカイブの URL が変わってしまう問題」や、「投稿を編集したときのタグ重複問題」(ベータ1は新規作成だけが改善されている!) が修正されています。
これで安心して使える感じでしょうか。今週中に正式リリースされそうですね。

WP 2.6 にしたらカテゴリー/タグ URL が変わってしまった
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% の場合でも同じ不具合が発生しますから、わりと重度な不具合だったと言えます。

WordPress 2.6 対応続き
なんとか 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 2.6 出てしまった
さきほど、WordPress 2.6 がリリースされたようです。まだ trac にチケットが多数残っていたはずなのに、リリース予定日を優先したようですね。少なくとも、WP_CONTENT_DIR, WP_PLUGIN_DIR 定数の変更によるディレクトリー変更機能はまだ使いものにならないと思います
日本語版は数日かかるでしょうから、それが出てからテストサイトに入れて拙作プラグインの確認を行い、当サイトに適用するか検討してみます。
[追記] 残っていた 760件のチケットはすべて 2.9 (!) に延期されていました。これは報告者が各自重要度に応じて 2.7 とかに戻せということですよね? (Y/y)

WordPress 2.6 対応つづき
拙作プラグインの 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 定数の設定機能は使用禁止という制限をつけざるを得ないようです。

WordPress 2.6 対応を盛り込む
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 への相対パスが一意に決まらないためです。うーん。どうしましょう。