「WordPress MU Plugin」 の方で「MUの1.5 RC1が出たからPlugin作成者はテストしよーぜ」というアナウンスが流れています。

WordPress MU 1.5は、1.3.3にWordPress 2.5の機能をマージしたバージョンです。
ボクも早めに時間をつくって、Left Handle BLOGSの1.5化をやりたいと思います。

データベース上でいうと・・・wp_postsテーブルのguidフィールドの話です。
GUIDとしてpermalinkが入っている思うのは、ちょっとした勘違い・・・そうボクもさっきまで勘違いしていたんですがｗ

多分、正解は・・・

投稿作成時のpermalink構造で作られたpermalinkが入っている。
後にpermalink構造を変更しても・・・または、ホスト名を変更しても、既存投稿のGUIDは置き換えてくれない。

ということだと思います。
まあ、GUIDの本来の意味を考えると、必ず「正しい」permalinkが入っているなんて思うのは間違っているに決まっていますね。

ちなみに、permalinkが欲しければwp-include/link-template.phpのget_permalink()を使うのが正解です。
（WordPress MUの管理機能などを作りこんでいる場合にpermalinkが欲しければ、get_permalink（）の前にswitch_to_blog()して、取得してから、restore_current_blog()する）

例えばimgタグやaタグに指定されるURLの正当性をチェックしてくれたりする機能です。

MUで記事を書いていて、aタグのtitle属性に「ブログ」と日本語で書くと、「ロ」の字が文字化けしてしまうという問題にぶち当たりました。
コードを追っかけていくとksesフィルターが化かしていることがわかりました。

このままでは、Left Handle BLOGS全体の問題として残ってしまうので、修正を試みたわけですが・・・

WordPress日本語版作成チームのGoogle Groupsに問題が指摘されていました。
さらに、チームの方がWordPress本家にもレポートしてくれていて、おまけにpatchも作ってくれています（要は、hrefやsrcのデータはフィルタするけど、altやtitle属性はフィルタしないという修正）。

早速、そのパッチをkses.phpに当てて、いろいろ試してみたところなかなかいい具合です。
大きいコミュニティのメリットを感じました。

Left Handle BLOGSにも早速採用です。

ちなみに、WordPress 2.3.3のkses.phpはMUとバージョンが違う為か、「ロ」問題はなかったです。
ただ、「ロ」だけが問題じゃなくて他の文字（エンコード）でも起こり得る話なので、対応したほうがいいと思います。
（WordPress 2.5のkses.phpは見てません）

NextGEN Galleryという画像ギャラリーのプラグインをいじっててわかったのですが、オプション設定を各ページor投稿の「カスタムフィールド」で上書きできる実装になってました。

ページや記事ごとに、表示オプションをカスタマイズできるというわけです。
この実装は良い感じですね。プラグインつくるときはパクリます。

いろんなところで書かれてますが、WordPressのビジュアルエディタ「TinyMCE」を使用して、コードの画面でゴリゴリとdiv要素を書いても、気が付いたら自動的にp要素に置き換えられてしまいます。

実に見事な余計なお世話だなとは思うのですが、サポートフォーラムでの回答によると、

<div> tags replaced by <p> How do I make it stick?

Since the DIV tag is considered more as layout markup the developers convert it to a paragraph to be more writer / semantic friendly.

と、divは主にレイアウトに使用するもので、コンテンツ中ではpを使うのが文章の書き手にも意味的にも優しいという考え方の元に決められた仕様だということですので、バグというには少し言い過ぎですね。

確かに「div厨」なんて言われ様があるくらい、困ったときはとりあえずdivを使う傾向ってのがあるので、コンテンツの中身ぐらいdiv無しで行こうぜって考え方には同意できますが、昔書いた記事のdivを全部pに書き換えろなんてのはカンベンして欲しいわけです。

この問題に嵌った人は決まって、wp-includes/js/tinymce/tiny_mce_config.phpの
$valid_elements =　‘p/-div[*],-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],-li[*],*[*]’;

を
$valid_elements = ‘p[*],-div[*],-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],-li[*],*[*]’;

なんて変更して回避してるんですが（もちろん僕もです）、これってアップグレードで上書きされて戻ちゃったりすると、そのときにはきっと忘れてるんで、さらなる悪夢に陥るハメに・・・

で、上の回答を書いた人がつくってる「WP Super Edit」というプラグインは、ソースコードを勝手に変更しないというポリシーでつくってるみたいなので、試してみる価値がありそうだぜ！

PHPのcacherをAPCからXCacheに変えたついでに、XCache for WordPressを入れてみたんですが、微妙なトラブルが発生。

管理画面で投稿記事を編集して、「保存して編集を続ける」を押すと、変更内容がリセットされちゃいます。

これは明らかにキャッシュが残っててクリアできてない・・・

どうやら「WordPress チューニング (Rauru Blog)」を見てその気になって、get_posts()の中にキャッシュに入れるコードを追加してたのが原因だったようで、そこを削除したら直りました。
しかし、別にそこでキャッシュするのは悪いことじゃないので、edit時にキャッシュ更新orクリアをしてやるべきですね。
まあ、あんまり勝手にいじるのは良くないなってことで、戻しておくことにしました。

しかしこのあたりのコード、あまりにも気になるのでsvn trunkのを見たのですが、かなり書き直されてるので2.5に期待しときます。

このブログにAll in One Adsense and YPNというプラグインでAdSense広告を挿入してみたところ、文字化けすると思ったら、なんだか文字列置換のところがテキトーになってたので、テキセツに直した
(more…)

WordPress MUの調査は続いています。

MUでユーザーに使ってもらう為のテーマを選ぶ為にいろいろ調べていると、以下のsubversion repositoryのパスが見つかりました。

http://svn.automattic.com/wpcom-themes/

wordpress.comで選べるテーマが全部ここに入ってるんです。
「これは、いいぞ」ってことで、早速checkoutして自分のテスト環境にインストールしてみました。

(more…)

名前からすると「存在するブログの一覧を取得する」機能と判断できますね。
もちろん、ボクもそう思いました。

しかし、コードをみるとblogsテーブルからselectするSQL文の条件に「public=’1′」 というのが含まれています。

この「public」というフィールドは、通常のWordPressでもおなじみの管理画面における「プライバシー」の状態を指しています。

「プライバシー」は、 「このブログを、検索エンジン (Google、Sphere、Technorati など) とアーカイブサイトを含め、誰でも閲覧できるようにする」かどうかのフラグで、具体的にはheadタグ内にmetaタグのnofollow, noindexを記述するかどうかというモノです。

となると、get_blog_list()内で「public=’1′」でフィルタするってのはなんなんでしょうか？

ソースコードをgrepすると、get_blog_list()は同じwpmu-functions.phpにあるget_most_active_blogs()という関数からのみ呼ばれています。
（get_most_active_blogs()はどこからも呼ばれていない）

う～ん、ナゾは深まるばかりです。

一つだけいえるのは、blogの一覧が欲しければ自分でfetchするしかないってことです。
WordPress MUの「サイト管理 - ブログ」画面のblog一覧も、get_blog_list()は使ってないのですから。

P.S.
この前、Plugin ManagerというMU用のプラグインについて書きました。
Plugin Commanderという別のものも見てみたのですが、どちらも少し「足りない」ので、自分で書くことにしました。
完成したらここで公開しまっす。