« Posts under Internet

MovableType5からWordPress3.0に移行

世田谷美術館

Movable Type5.0から、Wordpress3.0に移行した。

ボクのこのブログがWordPress Me 2.1.3からMovableType4.0に移行したのは2007年のことだ。それ以来、約3年ほどMovableTypeで運用してきたのだが、Wordpress3.0でマルチサイトがサポートされるのを機に再移行(出戻り)を検討していた。MTは嫌いじゃないのだが、バージョンアップのたびに複雑になり気楽にいじれなくなってきたことが主な動機。MTは、次第に商用向けに舵をとりはじめたことで個人ブログ向けには使いにくくなってきた気がするのだ。

そして、WordPress3.0 をインストールしてしばらく試してみた結果、再びWordPressに戻ることを決意。3年ぶりに使ってみたWordPressの進化ぶりは目を見張るほどで、最近のすさまじいまでのWordPressの普及を裏付けるものであった。

今回の移行にあわせて、これまで面倒で手を付けていなかったいくつかの課題に取り組んでみることにした。

ざっとならべると、

[text toolbar=”false” gutter=”false” font_size=”80%”]

1.WordPressへの移行

2.モバイル対応(iPhoneやAndoroid他、スマートフォンへの最適化)

3.ドメイン移転

4.デッドリンクの修正

6.パーマリンクや投稿スラッグの統一

7.分散したサイトの相互リンク

8.feedの適正化

[/text]

といったものである。10年以上ものサイト運用の過程で、システム切り替えや移行の度にちょっとづつ残ってしまっていた問題のゴミ掃除ともいえるかもしれない。とても一度にはできないボリュームなのだが、WordPressへの移行さえ済んでしまえばあとは何とかなりそうだ。

以下、WordPressへの移行についてまとめておく。

■データ移行の方法について

ネット上にはたくさんの移行のための情報があるので不自由はしないが、Movable Type (以下MT)からWordPress (WP)に乗り換えようとするときに必ずネックになってくるのが記事データ移行の問題。MTにもWPにも記事(投稿)のエクスポート/インポート機能があるので一見すんなりいきそうなのだが、そのときに移行できるのは、記事本文・コメントのみ。パーマリンク(URL)、カテゴリー、タグといった付帯情報は一切引き継ぐことができない。最も障害になるのはパーマネントリンク(パーマリンク)の扱いであり、これって致命的な問題なのだ。パーマリンクは、今までに張られたリンクや検索エンジンのインデックスを有効に生かすためのコンセプトであるはずなのに、どちらもそれに対応してないってのはどういうことか?おそらく、ユーザーの流出を防ぐためにわざと対応してないんじゃないかと思う。携帯で言うところの番号ポータビリティと同じだ。

MT・WPそれぞれのソースコードを修正してパーマリンクを引き継がせるなんてことはできるのだけど、この方法は、MT・WPがバージョンアップされて元のソースコード自体が変わってしまうと、どこを修正していいのか分からなくなってしまうのが欠点といえば欠点。

そこで、WPにはサイト移転などのために「WPからWP」の完全なエクスポート/インポート機能が備わっていることに着目。WPからWPへWXR(WordPress eXtended RSS)形式のデータを使ってブログ内容の引継ぎができるのであれば、MTからWXR形式でデータを書き出すことさえできればいいのではないか??と考えた。WPに限った話では無いと思うが、移行用のエクスポートファイルは移行先のツールに合わせたフォーマットの方が良いんじゃないか?と言うわけである。

MT上でWXR形式のデータを書き出せるプラグインのようなものなどはないものか・・と探していたら、頼りになるのはやはり先人の知恵。それが今回採用した手法である、’MovableTypeにWXR形式で書き出すテンプレートを作成してエクスポートする’というものだ。これなら基本的にはバージョンを意識する必要はなく、とてもスマートに移行を行えそう。

結果論からいうと、割とスムーズにインポート出来たんじゃないだろうか。今回はMTからの移行だったが、他のブログサービスやブログツールであっても、なんらかの方法で書き出しが可能ならば同じようにいけると思う。

参考:

MovableTypeからWordPressに固定リンク込みで完璧に移行する方法

ただしここで紹介されていたMTテンプレートは、MTのブログ記事で「追記」に記述された分は正しく書き出せなかった。

追記にも対応したテンプレートは、以下のサイトで紹介されている。

http://blog.s-satoshi.net/tech/mt2wp_greater_template/

■パーマリンクや投稿スラッグの修正

データ移行が解決したら、次はリンクの修正について。

パーマリンクについては、ボクのMovableTypeでは「yyyy/mm/entry-basename.php」だったので、WPでは「/%year%/%monthnum%/%postname%.php」という風にするのが一般的。注意するべきポイントは、WPでは新規投稿の際にタイトルに日本語が使用されているとスラッグも日本語名になってしまうということ。これをMovable Typeのように半角英数、キーワードのあいだはハイフン(-)にして、同じ名前があった場合に2とかにしてくれるようなプラグインもあるので紹介しておく(リンクはこちら)。

話はそれてしまったが、ボクのサイトはこれまで移行を重ねてきたせいか、このパーマリンクの命名がバラバラで統一感がなかった。あいだがハイフンだったり、アンダースコアだったりといった感じだったので、今回の移行を機に修正することにした。ただし、リンクや検索エンジンのインデックスを無駄にはできないので、これは301リダイレクト(後述)を使って継続性に配慮しなければならない。

MovableTypeのパーマリンクを移行

/blog/archives/201006/aaa-bbb-ccc.php

/blog/archives/%year%/%monthnum%/%postname%/

参考:

WordPressへ移行

パーリンクの問題 http://blogram.net/2010/02/25/permalink/

■RSSのURL修正

・RSSのURLが変更になるため.htaccessに以下を追加

[php font_size=”80%”]

Redirect 301 /atom.xml http://rightdice.com/feed

Redirect 301 /rss.xml http://rightdice.com/feed

Redirect 301 /index.xml http://rightdice.com/feed

[/php]

■画像URLの変更

wp-content/uploads/に画像を格納するために、Movable Typeでエクスポートしたデータ内にある画像URLを、任意のディレクトリに一括置換した。

ボクは「images」というディレクトリに一括で保存していたのでそれを丸ごと持ってくればよいかと思っていたのだけど、サムネイルの画像は「asset_cなんとか」というディレクトリに入ってしまっていた。MTのときの画像リンクを変更したくなければそのまま残しておいても良いかもしれない。今回僕はドメインも移行したので、そのまま残すことはせずに一旦すべてWPの「upload」ディレクトリにメディアインポートした。そして、インポート前にブログ記事(テキストファイル)上でリンクを一括変更し、とりあえずリンク切れが発生しないようにした。あとはのんびりと必要に応じて修正することにしよう。面倒な作業はこれとリダイレクト設定(後述)ぐらいで、他は拍子抜けするぐらいに簡単だった。

■リダイレクトの設定

パーマリンクのところでも少し触れたが、このリダイレクトが今回一番苦労したところかもしれない。長くなりそうなので詳しくは別の機会にあらためようと思うが、簡単にポイントだけ。。。。

リダイレクトにはざっと2つの方法がある。基本的な「Redirect permanentを使う301リダイレクト」と、Apacheのモジュールである「mod_rewrite」を利用する方法だ。ドメインが変わっただけとかファイルのパスや拡張子が変わった程度であればRedirect permanentでも十分なのだが、動的なクエリ付きページの場合(「~/example.php?id=01」など)や、条件判断を伴うような複雑なリダイレクトが必要な場合には、どうしてもmod_rewriteを使わなければならない。ただし、前述のようにmod_rewriteはApacheのモジュールなので、使用しているホスティングサービスでサポートされていることが必要となる。

ボクが使っているCOREサーバーは、mod_rewriteモジュールをサポートしているので、これを使ってリダイレクトの設定を行った。

詳細については、あらためて記述します。

※使用中のサーバーでmod_rewriteがサポートされているかどうかを確認するには、

<?php phpinfo(); ?>

とだけ書いたページ(test.phpなど)を作成してサーバー上におき、ブラウザで開いてみればよい。

参考:

「URLの書き換え Rewrite」

mod_rewrite URLを書き換えるApacheモジュール

■その他

・WordPressのプラグインで、WordPress > 404 Notifier ? WordPress Pluginsというのを入れておく。404ヒットがあったときにメールで通知orRSSフィードでお知らせしてくれるので便利だ。

 

Voxが今月一杯でサービス終了

入道雲

MovableTypeで有名な米Six Apartが日本を含む世界で提供している、ちょっと速いマイクロブログ「Vox」が10月1日早朝をもって終了する。

「【チームVoxより】 Voxは2010年10月1日早朝にサービスを終了いたします」

Voxは、TypePadに続く新ブログサービスとしてスタートしたもので、記事の公開範囲を絞れる機能を備えているのが特徴であった。
twitterやtumblrの台頭と比べて、Voxはいまひとつ盛り上がりにかけるものであったので、おそらくは開発リソースをTypePadやMovableTypeに集中するとかの事情がいろいろあるのだろう。
サービス終了にあわせて、Six Apart社は、Voxに投稿された記事をTypePad Proに移行したり、写真や動画をFlickrに移行するツールを提供している。TypePad Proは通常なら¥980/月の有償サービスだが、ツールを使って移行したVoxユーザーに限り、来年3月までは無料で利用できるような配慮がなされているそうだ。当たり前といえば当たり前のようにも思えるが、このへんはユーザーを大切にする同社の姿勢が感じられて素晴らしいなと思った。
ボクもVoxにアカウントは持っていたけど、お遊び程度に使っていただけなので、引越しをするほどでもない。そのままcloseしました。

WP3.0のマルチサイトでGoogleXMLSitemapプラグインを使う

トンボの写真

前に「WordPress 3.0のインストール」で書いたのたけど、WordPress3.0のマルチサイト環境において、現時点では「GoogleXMLSitemapプラグイン」を使用することができない。マルチサイトでの
子サイトはそれぞれ独立したサイトでありながら独自のXML Sitemapを生成しないため、ウェブマスターツールも上手く読み込んでくれないのだ。それぞれのサイトの「sitemap.xml」が同名で同じ場所に書き出されてしまうことが原因だ。対応版がリリースされるまではそんなに時間はかからないだろうけれど、それでもSitemapの自動作成ができないのは不便。なにか方法はないものかと探してみたら、「Google XML Sitemaps and WordPress Multisite」をみつけることができた。

GoogleXMLSitemap ver3.2.4

基本的には先のサイトに書かれている通りだけど、ボクの環境とは合わない部分もあったので少し手直した。サーバー環境によっては動作しないケースもあるかと思うので、あくまでも参考まで。。。

1.プラグイン管理画面の警告メッセージを非表示にするため、「wp-content/plugins/google-sitemap-generator/sitemap.php」を編集する。
ボクはインストール済みのプラグインを直接編集したけれど、もちろん、先にローカルで編集してからアップロードしても構わない。
56行目あたりの行を以下のようにコメントアウト(先頭に//をつける)する。
[php num=56 font_size="60%"]
//Check for 3.0 multisite, NOT supported yet!
//if((defined('WP_ALLOW_MULTISITE') && WP_ALLOW_MULTISITE) || (function_exists('is_multisite') && is_multisite())) {
//if(function_exists('is_super_admin') && is_super_admin()) {
// add_action('admin_notices', array('GoogleSitemapGeneratorLoader', 'AddMultisiteWarning'));
// }
//
// return;
// }
[/php]

2..htaccessにRewriteRuleを作成する。このとき、WordPressのRewriteRuleより前(上部)に記述すること。下に追記すると反映されない。
前述の英語サイトの例では、sitemapのRewrite先をルートディレクトリとして.htaccessに記述していたのだが、プラグインから自動的にsitemapを生成させるためには、ルートディレクトリのパーミッションが書き込み可能(「777」「757」「707」など)になっていなければならない。書き出しの都度パーミッションを変更するならいいのだけど、それではかなり面倒なので、プラグインから書き込み可能である blogs.dirに書き出すようにした。
また、blogs.dir下のサイトディレクトリ(blogs.dir/2/files など)に書き出すことも考えたのだが、RewriteRuleの記述が面倒になるのと、サイトのIDでしか識別できないディレクトリパスが煩わしかったので、全サイトをblogs.dir直下に書き出すようにした。もともとRewriteRuleで「sitemap-サイト名.xml 」または「sitemap-サイト名.xml.gz」とサイト固有のファイル名にしているので、同じディレクトリにあっても問題はないわけだし・・・
同様に、robotsについても、blogs.dir直下に「robots-サイト名.txt」というファイルを書き出している。robotsを使う場合は、プラグインの設定で「仮想robots」を無効にしておくことをお忘れなく。

[php num=1 font_size="60%"]
#Begin sitemap
RewriteEngine on
RewriteBase /
RewriteRule ^sitemap\.xml$ wp-content/blogs.dir/sitemap-%{SERVER_NAME}.xml [L]
RewriteRule ^sitemap\.xml\.gz$ wp-content/blogs.dir/sitemap-%{SERVER_NAME}.xml.gz [L]
RewriteRule ^robots\.txt$ wp-content/blogs.dir/robots-%{SERVER_NAME}.txt [L]
#End sitemap
[/php]

3.プラグインの管理画面で「GoogleXMLSitemapプラグイン」を有効にする。
このとき「ネットワークで有効化」ではなく、それぞれのサイトで有効化を行うこと。ネットワーク有効にするとsitemapが正しく作成されないので注意。

4.GoogleMapプラグインの管理画面では、サイトマップファイルの場所を「手動配置」にする。
先の.htaccessの内容を前提とすると、
[相対パス or 絶対パス]
/サイトルートまでのURL/wp-content/blogs.dir/sitemap-サイト名.xml
[完全なURL]
http://example.com/wp-content/blogs.dir/sitemap-サイト名.xml
と設定する。

あわせて、「サイトマップのURLを仮想robots.txtファイルに追加」のチェックは外しておく。
robotsについては、
[php num=1 font_size="60%"]
User-agent: *
Sitemap: http://examlpe.com/sitemap-サイト名.xml
Sitemap: http://examlpe.com/sitemap-サイト名.xml.gz
Disallow:
[/php]
という内容で robots-サイト名.txtを作成し、blogs.dirにアップロードする。

あとは、Googlenoウェブマスターツールに登録するだけ。これでマルチサイトでもsitemapが自動生成されるようになる。
願わくばマルチサイトに対応したプラグインを早くリリースしてほしいものだが、それまではこれで凌いでいくことができそうだ。

参考:
Google XML Sitemaps and WordPress Multisite
WP3.0ネットワークでGoogle Sitemapを作成する

ーーーーーーーーーーーーーーーー
追記:(2010年9月23日)

やはりというか、ようやくというか、WordPress3.0のネットワークに対応したGoogle XML Sitemapプラグインが登場した。
現在のリリースバージョンは ver4.0.2となっており、WP 3.0.1にも対応している。

Google XML Sitemaps with Multisite support

『Google XML Sitemaps』プラグインをベースとして、マルチサイト対応版として改善されたものだ。以前ここで紹介したような、phpファイルの書き換えや.htaccessの作成などは必要なくなり、インストールするだけで完全に動作している。
ボクもその一人なのだが、WP3.0をマルチサイトで使っているユーザーにとって待ちに待ったプラグインなのではないだろうか。。。

XAMPPで移行用の環境構築

桃の写真

今回のWordPressへの移行は、ちょっと試行錯誤が必要になりそうだ。テスト用としてレンタルサーバー上にテストサイトも用意してあるけれど、ローカルにもテスト環境が欲しかったので、気軽に扱えて便利と評判の高い「XAMPP」(ザンプ)というパッケージを使用した。XAMPPは、以前にも使用したことがあるので安心して使うことができる。

XAMPPについて少し説明しておこう。もう何年も前のことになるが、XAMPPのルーツといえる「LAMP」とよばれるWeb環境があった。
これは、

  • Linux  (OS)
  • Apache HTTP Server  (Webサーバ)
  • MySQL  (データベース)
  • Perl、PHP、Python (スクリプト言語)

を総称した頭文字から成る造語だ。動的(ダイナミック)なWebコンテンツを含むWebサイトの構築に適した、オープンソースのソフトウェア群のことをいう。これらはそれぞれ独自に開発されたものなのだが、いくつかのサーバー用Linuxディストリビューションにおいては、LAMPがセットになって配布されていた。LAMPを1つのセットにすることによって、OSのインストールの際にLAMPの多くの設定や関連付けを自動的に行えるようになり、サーバー管理者の手間を軽減させることができることから急速に普及した。僕も昔、これらのソフトウェアをLAMPを使わずに個別導入を試してみたことがあるのだけど、インストール、各設定ともに面倒でかなりシンドイものがあった。それがLAMPを使うことで設定に悩むことはなくなり、とりあえず動かす程度であればクリックするだけでおしまいだ。ほんといい世の中になったものだ。

そしてXAMPPとはこのLAMPから派生したもので、apachefriends.orgというオープンソース・プロジェクトから提供されている。LAMPと同様にWeb開発環境が一括して導入できるものであり、Linux以外の複数のOSに対応したことから'L'ではなく'X'(クロスプラットフォーム)として名づけられた。'P'が2個なのは、MySQLのGUIツールであるPHP MyAdminといったソフトウェアもパッケージに加わったことによる。現時点でXAMPPは、OSは、Windows、Linux、Mac OS X、Solarisで利用可能となっている。XAMPPは、主として開発用あるいは学習用とされているが、実用性も高いことから、イントラネットなどにおいて実運用環境として使われることも多くあるようだ。
今回ボクが使用したのは、「XAMPP for Windows」の最新バージョンである ver.1.7.3。ApacheFriends.orgの以下のサイトからダウンロードしてセットアップする。ボクは、デスクトップ機ではなく、Windows XPのノートPC (ThinkPad x40)に導入することにした。

『XAMPP for Windows』
http://www.apachefriends.org/jp/xampp-windows.html

XAMPPの基本的なインストールについては、上記のサイトで解説されているので割愛する。インストール自体はとても簡単で戸惑うことはないだろう。その他のポイントだけを記述する。

・セキュリティ対策
ローカル環境だある自宅のノートPC(Windows XP)に導入するわけなのだけれど、これが外部(インターネット側)からのぞけたりするとセキュリティ上とても危険である。.htaccessを使ったアクセス制限とMySQLのパスワード設定だけは忘れずに行っておくことにする。(.htaccessについては詳しくはこちらを参照)
まず、テキストファイルにこんな感じで記述。
[php font_size="80%"]
Order deny,allow
Deny from All
Allow from localhost 127.0.0.1
[/php]
この.htaccessでは、全ての接続要求を拒否(deny)し、唯一、localhostである127.0.0.1だけを許可(Allow)している。127.0.0.1というのはループバック・アドレスといって、規定でそのPC自身をさす特別なIPアドレス。この内容はつまり、「自分以外からのアクセスは拒否する」という意味。この.htaccessを、Apacheのドキュメントルートに置く。Windows版XAMPPでは、デフォルトのドキュメントルートは「C:\Program Files\XAMPP\htdocs配下」である。
ちなみに、Windowsの標準の「メモ帳」ではファイル名が「.」(ドット)で始まるファイルは保存できない。Explorerで名前の変更をすることもできない。「秀丸」や「サクラエディタ」といったテキスト・エディタ使用し、保存の際に「ファイルの種類」を「すべてのファイル(* *)」にすると保存できる。
このとき、エンコードの種類をWindows標準のShift-JISのままだと何かとトラブルの原因になったりするので、ここはUTF-8にしておくことをお勧めする。その意味でもテキスト・エディタはあった方がいい。

次にデータベースのセキュリティだが、データベースであるMySQLは、格納されたデータをPHPで取り出してWordPressの画面を生成したりしている。ここも外部からアクセスできては困るのだが、デフォルトではroot権限のユーザがパスワード無しになっている。これはさすがにあぶないので、DBに接続するユーザ、パスワードはきちんと設定しておく。

これら何点かだけ気をつけて、XAMPPを使ったWordPressの開発環境が簡単にできてしまった。ネットを介さず、ローカルマシンでちょっとしたテストや動作確認ができるのはほんとに便利で楽だ。WindowsのExplorerから直接ファイル操作ができ、そのままブラウザで確認ができる。FTPすら必要としない。テーマ、プラグイン、テンプレートなどのカスタマイズは、このテスト環境で試してからCOREサーバ上にアップすることにする。

参考:
「AMPPでWordPressローカル環境をつくる」
http://blackpepper.oops.jp/wp/archives/2077

WordPress 3.0のインストール

wordpress6月の末に、「WordPress 3.0 ”セロニアス”」の日本語版が正式にリリースされた。このリリースの愛称”セロニアス(thelonious)”は、ジャズ・ピアニストである「セロニアス・モンク(Thelonious Monk)」に由来しているのだそうだ。歴代のWordPressのコードネームはどれもジャズ・ミュージシャンの名前がついているけれど、これはWordPress創始者 Matt Wullenweg氏がジャズ好きであることから著名なジャズ・ミュージシャンの名前を付けているのだとか。

今回のリリースでの目玉としては、まず、新デフォルトテーマ「Twenty Ten (トゥエンティテン) 」の採用があげられる。テーマ制作者向けには、カスタマイズ可能な背景、ヘッダー、短縮リンク、メニュー、投稿タイプ、分類などを簡単に実装できる新しい API が用意されており、Twenty Ten テーマではこれらがすべて活用されている。もうひとつは、長い間待ちに待った WordPress とWordPress MU の統合である。新しいマルチサイト機能を使うことで、ひとつのWordPressのインストールだけで、複数のサイトを運用することが可能となった。MovableTypeでは以前からマルチサイトをサポートしていたとはいえ、ボクにとっては、これでMTに踏みとどまっていた要素がひとつ減ったと言える。WordPressの公式リリースによれば、今回のバージョン 3.0でリリースサイクルを一休みして、今後は WordPress 周辺を充実することにリソースを集中するとのことだ。

リリースノートをみているだけでワクワクしてくるWordPress 3.0。
早速テストサイトを立ち上げて試してみることにした。インストールについては、これまで通りの「5分間インストール」なので簡単。このインストールの方法については公式HPにも丁寧にかかれているので割愛するが、結論から言えば、WP3.0は素晴らしい!出来が良すぎて困ってしまうぐらいである。クイックポストを使って設定や投稿は簡単にできるし、モバイル対応も含めて使えそうなテーマやプラグインはいっぱいあるし、WP自身のバージョンアップですらボタン一つでできる。世に出ているテーマとプラグインを使うだけで、十分に満足できるサイトを作れそうなのだから、面倒なサイト構築の努力や勉強なんてしなくなってしまいそうだ。とりあえずしばらく使ってみることにするが、WP3に慣れたらもう他のCMSを使う気は無くなってしまうかもしれない。

参考:「WordPress のインストール」-WordPress Codex 日本語版

【マルチサイトの構築】
まずは、3.0の本命であるマルチサイトを早速ためしてみた。マルチサイトを構成手するには、wp-config.phpに、
[php font_size=”80%”]
define(‘WP_ALLOW_MULTISITE’, true);
[/php]
の1文を加えるだけ。ログインしなおすと、ダッシュボードの[ツール]に[ネットワーク]という項目が追加される。
この[ネットワーク]メニューを開くと設定手順が示されるので、それに従ってwp-config.phpや.htaccessを修正する。修正といっても、必要な設定内容は自動生成されて示されているはずなので、これをコピペするだけの簡単さだ。
一通り設定してログインしなおすと、特権管理者としてサイトを追加することができるようになる。

ちなみに、新しくサイトを追加すると、WP_と同じデータベース内にWP_2_という接頭辞のテーブルがもうワンセットできていた。
サイトが追加されるたびに、この接頭辞の異なるテーブルを追加していくということか。

参考:「ネットワークの作成」-WordPress Codex 日本語版

なお、wpを専用ディレクトリに配置している場合は、マルチサイトを構成することができない。これは、将来的に改善されることを期待しよう。

WordPress MU & 3.0
注意: この手順は、WordPress MU ならびに マルチサイト(multisite)を有効にした WordPress 3.0では動作しません。メンバーブログの参照を妨げます。

参考:「WordPress を専用ディレクトリに配置する」 -WordPress Codex 日本語版

【不具合のメモ】
・ダッシュボードのレイアウト崩れ
僕が主に使用するブラウザはFirefox3.5/Firefox3.6なのだけど、WordPress 3.0 のダッシュボードをブラウザで開くと、管理画面のCSSが正しく反映されず、縦一列にズラズラと並んでしまうので困った。FirefoxだけではなくGoogle Chromeでも同様だったのだが、なぜかIE8では正常に表示される。しばらくは原因追求を後回しにしてIEを使っていたけれど、やはりFirefoxが使えないのはとても不便。・・・原因を探るべくネットを調べてみると、レイアウトが崩れるのはどうもApacheのmod_layoutが原因であるらしい。

ダッシュボードのCSSはwp-admin/load-style.phpで動的に生成されるようになっているのだが、通常ならtext/cssとして送信される情報が、mod_layoutでtext/htmlとして送信されていることがわかった。FirefoxではこれはCSSとして扱わないので、結果として表示が崩れているのだ。
これは、僕が使っているCORE サーバーやXREAで起こりうる特有の症状らしい。COREサーバーやXREAの場合、PHPはセーフモードで動作するので .htaccessを使って.phpをCGIとして動作させている。これまでのMovabletypeの環境では、XREAのサポート情報(http://sb.xrea.com/showthread.php?t=10744)に沿って、.htaccessに「AddHandler application/x-httpd-phpcgi .php」の一文を記述していたのだが、これが原因であった。

解決策としては、wp-adminディレクトリの.htaccessに
[php font_size=”80%”]
<Files load-styles.php>
LayoutIgnoreURI *.php
</Files>
[/php]
を記述を書き加えることで解決。ForefoxでもGoogle Cromeでも表示は正常になった。
それにしても、どうしてIE8で問題なく表示できていたのだろう??
(あいかわらず唯我独尊のブラウザだなぁ。。。。)

参考:
「XREA・CORESERVER.JP にて CGIモードで動かす場合(まとめ)」-WordPress Codex 日本語版
「ブログ入門」-WordPress Codex 日本語版

・GoogleXMLSitemapの問題
2010/8月現在、WordPress3.0のマルチサイト環境下では「GoogleXMLSiteMapプラグイン」が利用出来ない。簡単にいえば、マルチサイトそれぞれのsitemapが同名で同じ場所に書き出されてしまうことによるものだ。対応されるのは時間の問題とは思うのだけれど、SiteMapの自動書き出しができないのは不便。なにか方法がないものかと思っていたら、「WP3.0ネットワークでGoogle Sitemapを作成する」で対処方法が紹介されていたので参考にさせていただいた。