Wordpress 2.9.2 がリリースされました。日本語版もダウンロードできます。

今回はセキュリティに関する修正があり、複数のユーザを登録して使っている場合に、他人が削除した（ごみ箱に入れた）投稿記事が見えてしまうというバグの修正です。複数ユーザで運用している場合はすぐにアップデートしましょう。

Wordpress 2.9.1がリリースされました。日本語版もダウンロードできるようになっています。2.9 での細かいバグフィックスなどが行なわれているということです。

あと、SimpleTag プラグインの 1.7.1 rc1.2 が出ていますね。これで前回の記事のような書き換えはせずに、2.9 系列でも利用できるようになりました。

2.9 からは、MySQL の 4.1.2 以降が必須となっています。まあ MySQL 4.0 系列のサポートはすでに打ち切られているので、いつこうなってもおかしくありませんでしたが、一部のレンタルサーバなどではまだ 4.0系列を使っているところもあり、バージョンアップしようとするとエラーが出てしまいます。

また、バージョンアップすると、プラグインとして利用してる “Simple Tags” が動かなくなっしまいました。次のようなメッセージが出ます。

Simple Tags can't work with this WordPress version !

暫定的な回避策として、プラグインを編集して、

if ( strpos($wp_version, '2.7') !== false || strpos($wp_version, '2.8') !== false  ) {

の部分を

if ( strpos($wp_version, '2.7') !== false || strpos($wp_version, '2.8') !== false || strpos($wp_version, '2.9') !== false ) {

に変更することで対応できました。

WordPress 2.7 以降では投稿リビジョン機能が備わりました。投稿を変更した履歴が保存できるので、間違って消してしまったときや、変更したけど元に戻したいときには重宝します。しかし、1つの履歴は1つの投稿と同じだけデータベースを消費します。誤字の修正程度でも変更を保存すればデータ量がどんどん増えていきます。何度も記事を推敲しているだけでレコード数がふくれあがります。

そこで、投稿リビジョンを無効にするにはどうすればよいでしょうか。無効化するプラグインなどを使っている方もあると思いますが、実は投稿リビジョンを無効にするには、wp-config.php ファイルに次の1行を追加するだけで可能です。

define('WP_POST_REVISIONS', 0);

これで投稿リビジョンは無効になりました。（ただしオートセーブは1つだけ保存）。投稿リビジョンの保存上限数を指定することもできます。

define('WP_POST_REVISIONS', 3);

ところでデータベースにはこれまで作成されたデータが残っていますので、MySQL のコンソール（または pphMyAdmin）で、以下の SQL を実行してすべて削除します。wp-config.phpで $table_prefix を 変更している場合は、テーブル名を読み替えてくください。

DELETE FROM wp_posts WHERE post_type='revision';

post_status ではなく post_type でマッチさせることに注意してください。なお実行前に必ずデータベースのバックを取った上、自己責任でお試しください。

アップデートの際に気づいたのですが、2.8.1 までは、アップデートの画面に 2.8.1-ja と 2.8.1 というように表示されていたと思うのですが、今回は 2.8.2-en_US が英語版として表示されているので違いが分かりやすくなったと思います。

もちろん日本語版を使っている方は、2.8.2-ja へのアップデートで OK です。

以前の記事にも書きましたが、FTP 設定の画面が出てうまく自動アップグレードできないときは、WordPress のディレクトリのパーミッションや所有者が適切に設定されていないと思います。Apache の実行権限で書き込めるように設定する必要があります。

バージョンアップ画面で英語版と日本語版両方が出ることがありますが、日本語版だけ選択すれば大丈夫です。崎に英語版にアップグレードした場合は、日本語版へのアップグレードを促すメッセージが表示されますので、必要に応じて実施して下さい。

WP2.8 での一番の新機能は、テーマの検索と自動インストール機能でしょう。

WPの管理画面からテーマをキーワードや分類などから検索し、プレビュー、インストール、適用がスムーズに出来るようになりました。頻繁にテーマを変更している方には便利な機能ではないでしょうか。

あとは細かい点ですが、画像のアップロードでファイル名に日本語を含む場合、これまでは文字化けしていましたが、2.8 では文字化けせずタイトルに反映されるようになったのが嬉しい改善点ですね。

実は、前回のアップデートでは、2.7.1 の英語版のファイルのみ上書きされたようで、今回は 2.7.1（英語版）→2.7.1ja（日本語版）へのアップデートのようです。

WordPress の wp-pass.php を狙ったあやしいアクセスがありました。

xxx.xxx.xxx.xxx - - [13/Feb/2009:14:22:41 +0900] "GET /wp-pass.php?_wp_http_referer=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ HTTP/1.1" 302 - "-" "XXX<? echo \"w0000t\"; ?>XXX"
xxx.xxx.xxx.xxx - - [13/Feb/2009:14:22:44 +0900] "GET /wp-pass.php?_wp_http_referer=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 302 - "-" "XXX<? echo \"w0000t\"; ?>XXX"
116.121.201.xxx - - [13/Feb/2009:15:53:34 +0900] "GET /wp-pass.php?_wp_http_referer=http://www.jeugdskating.nl/****/** HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows; U; Windows CE 4.21; rv:1.8b4) Gecko/20050720 Minimo/0.007"
116.121.201.xxx - - [13/Feb/2009:15:53:38 +0900] "GET /wp-pass.php?_wp_http_referer=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ HTTP/1.1" 302 - "-" "XXX<? echo \"w0000t\"; ?>XXX"
116.121.201.xxx - - [13/Feb/2009:15:53:39 +0900] "GET /wp-pass.php?_wp_http_referer=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 302 - "-" "XXX<? echo \"w0000t\"; ?>XXX"

似たような例として wp-pass.php狙いの怪しいアクセス というのがありました。どうやら以前 wp-pass.php にあった脆弱性（Bugtraq: Redirection Vulnerability in wp-pass.php, WordPress 2.2.1）を狙っているようです。

最新版にしていればスルーでよいのでしょうか。/proc/self/environ をリファラーとしてセットするというのはどういう攻撃なんでしょうね。

「WordPress 2.7.1. が利用可能です！　アップデートしてください。」のメッセージが出たので、「アップデートしてください」のリンクをクリック。

アップデート前の画面では、バックアップを取ることを薦められます。万が一に備えてバックアップを取りましょう。バックアップ作業が一番時間がかかるところです。バックアップしたら、「自動アップグレードを実行」を押します。

アップグレード用のファイルがダウンロードされ、自動的に更新されました。これで終了です。とても簡単ですね。

ところが、次のような接続情報を要求する画面がでてうまくいかないことがあります。

サーバの WordPress のディレクトリに設定されているパーミッションが適切に設定されていない（Apache の書き込み権限がないなど）場合に、この画面が出ます。パーミッションを見直して、正しく設定してください。いくら書き込み権限が必要だからといって、すべてのファイルのパーミッションを 777 にしてはいけません。

それにしても、上記画面に FTP サーバの接続情報を設定してもうまく動作した試しがありません。セキュリティ上もここに FTP のユーザ・パスワードを書き込むのは避けた方が無難です。

しかし、これを設定しただけではメールを送っても全く投稿されませんでした。PCからでも、携帯からでもどちらも動作しません。最初は cron か何かで定期的にメールボックスをチェックしてくれるのかと思ったのですが、そうではありませんでした。

実はメール送信後に、 http://(WordPress の URL)/wp-mail.php というファイルに、毎回アクセスする必要があります。この URL を叩くと PHP のスクリプトが作動して、メールボックスにアクセスしてくれるのです。

ここで気になったのは、wp-mail.php にアクセスしたときに投稿したメールアドレスやタイトル（文字化けしていますが）が表示されてしまうことです。しかも、WordPress へのログインの有無に関係ありません。

不用意にメールを送りっぱなしにしたまま放置していると、第三者にメールアドレスを知られてしまう可能性があります。

また、このファイルに集中アクセスされることにより、メールサーバに負荷をかけられる攻撃を受ける可能性があります。
そこで、この wp-mail.php ファイルはリネームして、推測できない別の名前にしておいた方が良いでしょう。メール投稿を使わない場合は、削除しておいた方がよりよいです。

ところで、このメール投稿機能でメールのタイトルに日本語を使うと文字化けしてしまいます。これはリネームした wp-mail.php の 146 行目を直接変更します。

$subject = trim($subject);
$subject = mb_convert_encoding(mb_decode_mimeheader($subject), "utf-8");　//←追加

続いて、本文の文字化けも修正します。同じく 158 行目に追加します。

$content = trim($content);
$content = mb_convert_encoding($content, "UTF-8" , "auto"); //←追加

これでメール投稿機能で日本語でも正常に使えるようになりました。

私も UTW を使っていた関係で、この UTWRenderThing を使っていたのですが、エラーログに次のような記録がかなり出ているることに気づきました。

PHP Warning:  Invalid argument supplied for foreach() in /wordpress_install_dir/wp-content/plugins/UTWRenderThing.php on line 561

タグを元に関連記事をリストアップしくれる UTW_ShowRelatedPostsForCurrentPost 関数を使ったときに、タグが1つも設定していない記事だと、foreach ループで回すための変更に配列が格納されずにエラーとなるようです。

そこで、 UTWRenderThing.php の561行目の前に次のコードを入れて、配列かどうかをチェックするようにしました。

  $tagids = array();
  if (!is_array($tags)) return NULL; //←この行を追加
  foreach($tags as $tag) {

これでエラーログに該当のエラーは出なくなりました。

まずテーマエディタのヘッダのテンプレートを編集。<head>～</head>内に以下のコードを追加。

<script type="text/javascript" src="http://s.hatena.ne.jp/js/HatenaStar.js"></script>
<script type="text/javascript">
Hatena.Star.Token = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXX';
Hatena.Star.EntryLoader.headerTagAndClassName = ['要素名','クラス名'];
</script>

Hatena.Star.Tokenの部分ははてなのアカウントをとって、ブログの URI を登録すれば得られます。という上記のコードが生成されるのでまるまるコピーします。

しかし、このままでは、各エントリーのタイトルが h3 要素になっているブログでないとスターが表示されません。本サイトのように
h2 要素を使っている場合でも、Hatena.Star.EntryLoader.headerTagAndClassName に要素名とクラス名を設定すれば OK です。

またはてなスターの★マークの画像を指定することもできるようです。この場合は、Hatena.Star.Star.ImgSrc に画像の URI を指定すればよいようです。

参考文献

• Wordpress ではてなスターを使う
• Wordpressにはてなスターの色を変えて設置
• [観] はてなスターを設置してみました

Akismet

言わずと知れたデフォルトで入っているスパム対策プラグイン。ただ有効にしただけではダメで、Askmet の API キーが必要。無料で取得できる。Movable Type のときはスパムコメントとトラックバックに辟易させられていましたが、WordPress で Askmet を使うようになってからはほとんど悩まされなくなりました。たまに日本語のスパムを通してしまいますけど。

akismet-multibyteview

Akismet では、問題ないコメントやトラックバックが間違ってスパムに分類されてしまうことがあるため、たまにチェックする必要がありますが、このプラグインを使うとマルチバイトが使われているコメントだけを表示できますので探しやすくなります。

WordPress Database Backup

これはデフォルトで入っていたような気もしますが、最新版はメールでのバックアップも可能。ローカルにダンプしてもサーバごと潰れたら意味がないので、遠隔地のメールストレージ（たとえば Gmail）に定期的にバックアップするというのがおすすめです。

Full Text Feed

RSS フィードを lt;!-- more --> 移行も含めて全文配信できるようにしてくれる。詳しくは「WordPress 2.1 で RSS を全文配信（+HTML形式で配信）する方法」を参照。

Google Sitemaps

Sitemaps Protocol に対応したプラグイン。Google や Yahoo にサイトマップ形式のファイルを提出してくれるので、クローラの巡回での取りこぼしが少なくなります。

被ブックマーク数表示＋ランキング生成プラグイン

はてなブックマーク、del.icio.us、livedoor Clip、Yahoo ブックマークの被ブックマーク数の表示と、それらブックマーク数によるランキング表示をしてくれるプラグイン。PHP の short_open_tag を無効にしている人は WordPress 被ブックマーク数表示プラグイン と PHP の short_open_tagも参照のこと。

Ultimate Tag Warrior

WordPress にタグ機能を附加する最強のプラグイン。高機能ですがバグも多いです。タグをもとに関連リンクを表示する機能もついています。WordPress 2.3 移行ではタグ機能がつくためにこのプラグインは開発終了し、WordPress のタグデータを活用するプラグインが開発予定とのこと。Ultimate Tag Warrior Final とバグ修正も参照してください。

Ultimate Google Analytics

Google Analytics を使うためのコードを各ページに自動で埋め込んでくれるプラグイン。

Google Sitemaps Generator

WordPress で Google Sitemaps の XML サイトマップを自動生成してくれるプラグイン。YST にも対応。

Search Regex

管理画面から記事の正規表現検索できる全文検索・置換プラグインです。ちょっと不具合ありですが有用です。

WordPress 2 以降ではアップロードした画像の記事への挿入も AJAX を使ってかなり便利になっています。しかし img 要素に画像の幅と高さが自動で入らないので、入るようにしてみました。これでブラウザが画像を読み込んでからレイアウトを再計算しなくて良くなるので、表示速度が若干拘束されるはずです。

試したのは WordPress ME 2.2.3 です。修正するのは wp-admin/upload.js ファイルです。修正箇所が多いのでファイルごと入れ替えてください。IE7 と Firefox 2 で動作確認しています。

以下、修正の考え方を説明します。読まなくても使えます。

239 行目付近の部分で img 要素の文字列を作っている箇所があります。ここで width と height が指定すれば良さそうです。しかし、this.currentImage.width と this.currentImage.height はサムネイル画像の、しかもサイズが合っていない値になります。

そこで、JavaScript の Image オブジェクトを使ってサムネイル画像またはフルサイズ画像を取得して、width と height を取得することにしました。しかし、Image オブジェクトは生成して src を指定してからすぐに width と height を参照しても 0 が返ってくるだけです。画像がまだ読み込まれていないからです。(キャッシュにある場合は値が返ってくる。)

そこで、Image オブジェクトの complete が true になるまで待てばよいのですが、JavaScript の宿命で wait や sleep に相当するものがありませんので、setTimeout ないし setInterval 関数を使って、ロジック部分を別関数化して呼び出す必要があります。これに伴い変数もグローバル変数にする必要がありました。

さらに何らかの理由で画像が取得できなかった場合でも無限待ち（ループ）に陥らないように制限もかける必要があり、大幅な変更になりました。

しかし UTW の作者は WordPress のタグデータを利用して、UTW の機能を実現するプラグインの開発を表明しています。データの移行さえできちんとできれば、今後も UTW のデータや機能が使えなくなることはなさそうです。

それにしても Ultimate Tag Warrior で記事が検索対象にならないバグ や、Ultimate Tag Warrior でプライベートな記事や草稿が表示されるバグ は相変わらず直っていませんでした。手作業で修正しましょう。

また、「UltimateTagWarrior」のバグについて | AOINA.COM によると、http://example.com/?archive=tag という URL にアクセスすると、エラーが発生するという不具合があるそうです。こちらも修正しておきましょう。

• 管理画面の記事一覧に被ブックマーク数を表示
• Yahoo!ブックマークを追加（以下略）

ということなので、バージョンアップしてみました。

……が、うまく動きません。

出力結果を調べてみると、PHP のコードがそのまま出力されています。コードを見ると <?= ・・・ > のような短縮形で書かれています。これは PHP のShortOpenTag の形式ですが、このサーバのように php.ini で short_open_tag=OFF に設定されているサーバでは利用できない記述形式です。な

php.ini で short_open_tag を有効にできるのであればそれで解決しますが、その場合でも PHP ソース中の XML 宣言とぶつかるなどの別の不具合が生じます。私の環境では、これが理由で OFF にしています。

short_open_tag が無効な環境でプラグインを動作させるようにするには、 template_post.php と template_list.php を修正し、<?= ・・・ ?> の部分を <?php _e(・・・)?> に書き換えてください。 <?php echo ・・・?> に書き換えてください。この形式あれば short_open_tag の on/off に関わらず動作します。

それぞれの内容を確認すると、URL が http://example.org/?attachment_id=1116 のようなおかしな状態になっています。

この URL を修正すれば良さそうですが、管理画面からは URL は変更できません。もしかしたらプラグインで編集できるものもあるかもしれませんが、今回は MySQL のコンソールから作業しました。もちろん phpMyAdmin からでも修正可能だと思いますが、私は試していません。

そもそもアップロードした画像の情報がどこに格納されているかというと、それぞれの記事やページと同じように wp_posts (wp_ の接頭辞は環境により異なっている場合があります) テーブルに格納されています。ここが WordPress の特徴です。このテーブルの guid というカラムに、先ほどの URL が格納されています。ためしに正常に表示される画像と比べてみると、

mysql> select guid, post_mime_type from wp_posts where id=1116 or id=1024;
+------------------------------------------------------------+----------------+
| guid                                                       | post_mime_type |
+------------------------------------------------------------+----------------+
| http://example.org/wp-content/uploads/2007/08/sapari.jpg | image/jpeg     |
| http://example.org/?attachment_id=1116                   |                |
+------------------------------------------------------------+----------------+

post_mime_type の値が空になっているのでこれを修正する必要がありそうです。また guid　の URL の形式がまるで異なるのがわかります。この URL を修正すればよいのですが、画像の内部バスが wp_postmeta テーブルに格納されているのでそれを利用します。

mysql> select meta_value from wp_postmeta where post_id=1116 and meta_key='_wp_attached_file';
+------------------------------------------------------------+
| meta_value                                                 |
+------------------------------------------------------------+
| /old/site/path/wp-content/uploads/2007/07/search-regex.png |
+------------------------------------------------------------+

しかし、wp_postmeta テーブルには、インポート前のサーバ上の内部パスが格納されていました。まずこれを修正します。

mysql> update wp_postmeta set meta_value=replace(meta_value, '/old/site/path/', '/new/hoge/path') where meta_key='_wp_attached_file' and meta_value like '/old/site/path/%';

次にこのデータを利用して、wp_posts を更新しますが、こちらは SQL 一発というわけにはいきません。個別に ID と mime_type を確認・指定しながら SQL を実行します。一気にやる方法は MySQL にはカーソルをループで回して……のようなことをやる術がないので、おそらくできないと思います。あれば教えてください。こういうときに Oracle や PostgreSQL と MySQL の差が出てしまいますね。

mysql> update wp_posts set
    -> guid = (select replace(meta_value, '/new/hoge/path/', 'http://example.org/')
    ->  from wp_postmeta where post_id=1116 and meta_key='_wp_attached_file'),
    ->  post_mime_type='image/png' , where id = 1116;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

もちろん post_mime_type には画像が JPEG のときは image/jpeg を、PNG のときは image/png を指定します。これで、アップロードしたファイルを確認してみると、

これを繰り返していき、すべての画像が復旧できました。

この画像が表示されなくなる現象は再現性があるので、WordPress のインポートプログラムのバグだと思います。将来的には改善されると思いますが、同じことでハマって悩んでいる人の助けになれば幸いです。

調べてみると。同じ問題に突き当たっている方がいました

#3066 (backslash disappears in <pre>) – WordPress Trac – Trac によれば、これは<pre>の中だけで起こる問題らしいです。speech markのためにバックスラッシュ追加してるとかなんとか書いてあるけど、これが仕様ってこと？

　で、さらにリンク先を見てみると、milestone set to 2.4 (future) なんて書いてあります。つまり 2.4 までに直す目標を設定したということで、すぐに対処される気配はなさそうです。

とりあえずの回避策としては \ を表示したければ &#x5c; または &#92; と書くしかありません。これが￥記号になるかバックスラッシュになるかはブラウザや指定されているフォントなどのクライアント側の環境によります。（制御記号としてではなく、文字記号として ¥ を表示したかったら &yen; と書く）連続ハイフンの扱いの件といい、WordPress も謎な仕様があって結構ハマりますね。

さて、この選択部分の本文は引用になるので、blockquote タグで囲まれるようにしてみました。本当はプラグイン化するのがよいのでしょうが、PHP ソースを直接いじった方が楽なので。編集するのは admin-functions.php の 376 行目付近（Wordpress 2.2.1 の場合）

$post_content = '<a href="'.$popupurl.'">'.$post_title.'</a>'."¥n$text";

の部分を私好みに次のように変更してみました。

$post_content = "<p>¥n".'  <a href="'.$popupurl.'" title="'
               .$post_title.'">'.$post_title."</a>¥n</p>¥n"
               ."<blockquote cite=¥"$popupurl¥" title=¥"$post_title¥">¥n"
               ."<p>$text</p>¥n</blockquote>¥n";

これで選択部分が blockquote 要素で引用され、cite 属性に URL が、title 属性にタイトルが自動的に入ります。個人的にはこれで手間が格段に違いますが、そもそもビジュアルリッチエディタを使っている人にはピンと来ないでしょうし、HTML に別のこだわりのある人もあるでしょうから、誰にでも役に立つ Tips だとは思いませんが。

まず Wordpress にユーザを追加

WordPress は複数のユーザを作成できるので、ペット用のアカウントを追加します。管理画面の「ユーザー」-「ユーザー設定」画面の下の方に「ユーザーの追加」がありますのでこちらから追加します。権限は「投稿者」にする必要があります。

BlogPet の設定

BlogPet にログインしたら「各種設定」の「基本設定」-「ブログ」を選択。ブログとフィードの URL を記述します。WordPress であれは通常は「ブログの URL を再設定」から設定すれば自動的に入ります。

次に下の方へスクロールして、ペット用に作成したアカウントのユーザ名・パスワードを記入します。「投稿用 API の URL」欄にはブログの URL に xmlrpc.php をつけたものを記述します。たとえば WordPress の設置場所が http://example.com/wordpress/ であれば http://example.com/wordpress/xmlrpc.php になります。Blog判別用 ID は 0 でよいでしょう。（Wordpress-MU の場合は異なるかもしれません。）

ここまで設定したら、いちどブログエディタから、テスト投稿をしてみます。うまく投稿できない場合は設定を確認してください。

貼り付けコードの取得

つぎに「ペットの設定」に進み、貼り付けコードを取得します。

クリップボードにコピーします。

テーマテンプレートの編集

再び WordPress の管理画面に戻ります。「表示」-「テーマエディタ」を指定して、「サイドバー」を開きます。ペットを表示させたい場所に先ほどのコードを貼り付け「ファイルを更新」を押します。ブログのサイドバーにペットが表示されていることを確認します。これであとはペットが記事を書いたりコメントしてくれるのを待ちましょう。