« Posts tagged WordPress

WordPressの記事にFlickrの写真を直接貼り付ける

移行の際にも感じたのだが、写真が増えてくるとWordPressのメディアライブラリですら管理が煩わしくなる。ボクは、オンラインアルバムや写真の整理には以前からFlickrを利用していたのだけど、やはりFlickrの方がWordPressのメディアライブラリよりもずっと使い易く高機能である(英語版しかないのが少々面倒ではあるが)。せっかくなので、WordPressの記事に掲載する写真も、Flickrから直接張り付けられないものか・・・と思っていたら、素晴らしいプラグインがありました。

WordPress Media Flickr (ver 1.1.1)
http://wordpress.org/extend/plugins/wordpress-media-flickr/

インストールは簡単で、作者のページで掲載されています。
http://factage.com/yu-ji/2008/03/31/wordpress-media-flickr-1_0_0/#comment-519
作者のYu-ji!さん、ありがとうございました。

今回は
・WordPress 3.0.1
・WordPress Media Flickr v1.1.1 プラグイン
・Flickrアカウント
で動作確認できました。

1. ダウンロードしてきて解凍(WP3.0の場合は、プラグインから検索&インストールでできます)
2.FTPなどで/wp-content/plugins/のplugins内にアップロード
3.WordPressの管理メニュー「プラグイン」を開いて、「WordPress Media Flickr」を有効にします
4.管理メニュー「設定」に「Media Flickr」が表示されているはずなので選択します。
5.二つボタンが並んでいるので、ユーザー情報に自分のflickrのユーザー名を入力して上のボタンを押します
6.Flickrのサイトに接続され、以下の認証画面が表示されます。「許可していいか?」と書いてあるので、この例では右のNEXTボタンを押します。
Media Flickr
6.Flickr側で「許可しますた」と表示されるはず(英語)です。もう一度WordPressに戻って、今度は下の「完了」ボタンを押します。
7.おわり

記事の投稿画面のツールバーにFlickrアイコンが増えていると思います。
Media Flickr
このFlickrアイコンをクリックするとWordpress Media Flickrのダイアログが表示されて、自分のFlickrに登録してある写真が一覧表示されてるはず。さらに、写真をクリックすると写真の掲載位置を選択する画面が表示されます。位置を選択して「挿入」をクリックすることで記事に貼り付けることができます。

Let’s enjoy

mod_rewriteを使ってのリダイレクト設定

青葉城
※D700+TAM DiSP 90mm (272E)

WPへの移行にあわせてドメインも移転した。検索エンジンの結果で表示されるページのURLが変更されるため、サーバー サイドの301リダイレクトを使用してリダイレクト設定をおこなった。301ステータスコードはページが新しいサイトへ移動したことを意味するので、これで検索エンジンが移転先のページにたどり着くことが保証される。ちょっとしたSEO対策にもなるので、忘れないうちにメモしておこう。

■基本のリダイレクト – 「Redirect permanent」を使う301リダイレクト設定
基本的に301リダイレクトは、以下の書式で.htaccessファイルに記述すれば可能だ。
ただ、試行の結果、この方法ではボクの目的を遂げることはできないことがわかったので、今回の移行では使っていない。

Redirect 301 /oldblog http://example.com/newblog

もしくは、

Redirect permanent /oldblog http://example.com/newblog

2つの構文はどちらも同じ意味であり、「/oldblog 」がリダイレクト元、「http://example.com/newblog 」がリダイレクト先である。
ちょっと紛らわしいかもしれないが、リダイレクト元はURLのルートからのパスを記述する(サーバーの物理的なフルパスなどではなく、大雑把に言うならURLからドメイン名を省略したもの)。そして、リダイレクト先には「http://~」といったURL全体を記述する。
後者の構文では「permanent」のくだりが「301(完全な移動)」であることを伝えてくれるステータスになる。「permanent」がなく「Redirect」のみだと、検索エンジンには「302(一時的な移動)」と解釈されてしまうので、サイトの移転など二度と戻る可能性がない場合は必ず「permanent」を記述するようにする。

参考:
301リダイレクト

■mod_rewriteを使っての301リダイレクト設定
ボクが今回使ったリダイレクトがこの方法だ。前述のRedirect permanentを使う方法では、クエリ付きの動的なページは、うまく動作してくれなかった。クエリとは、サーバーに渡す値や文字列データを指定するための「?」の後にある引数やその数値のことで、クエリを用いた動的なページとは”aaa.php?id=01”などのようなページリンクのことである。
他の方法を探していたところ「Rewrite」を使う方法が見つかったのではあるが、このRewriteで使われる正規表現がややこしい。一つ試しては失敗、また違うものを試しては失敗・・・・といった試行錯誤をしばらく繰り返していた。
そんなこんなだったが、こんなボクでもようやくRewriteの使い方が理解できてきたのでメモしておくことにする。

ボクがしたかったのは、
[text gutter="false"]
1.サブディレクトリを変更
2.拡張子のphpは取り除く
3.アンダースコアが含まれる場合、ハイフンに変更
4.日付アーカイブの場合にはパスを変更
[/text]
といったリダイレクトである。
つまり、こういうことだ。

http://from_example.com/blog/archives/2010/09/post_123.php

http://to_example.com/blog/2010/09/post-123/

http://from_example.com/blog/archives/2010/09/

http://to_example.com/blog/2010/09/

試行錯誤の末、以下のように .htaccess を記述することで意図した通りのリダイレクトを実現できた。もっとスマートな方法はあるとは思うけど、とりあえずは問題もなさそうである。
[php num=1 font_size="60%"]
RewriteEngine on
RewriteBase /blog/archives/
RewriteRule ^([0-9]+/)([0-9]+/)([^_]+)_([^_]+)_([^_]+)_([^_]+)_([^_]+)\.php$ http://to_example.com/blog/$1/$2/$3-$4-$5-$6-$7/ [NC,R=301,L]
RewriteRule ^([0-9]+/)([0-9]+/)([^_]+)_([^_]+)_([^_]+)_([^_]+)\.php$ http://to_example.com/blog/$1/$2/$3-$4-$5-$6/ [NC,R=301,L]
RewriteRule ^([0-9]+/)([0-9]+/)([^_]+)_([^_]+)_([^_]+)\.php$ http://to_example.com/blog/$1/$2/$3-$4-$5/ [NC,R=301,L]
RewriteRule ^([0-9]+/)([0-9]+/)([^_]+)_([^_]+)\.php$ http://to_example.com/blog/$1/$2/$3-$4/ [NC,R=301,L]
RewriteRule ^([0-9]+/)([0-9]+/)$ http://to_example.com/blog/$1/$2/ [NC,R=301,L]
RewriteRule ^(.*)\.php$ http://to_example.com/blog/$1/ [NC,R=301,L]
[/php]
この.htaccessファイルを、転送元サーバ(旧サーバー)上の2行目で指定した場所「/blog/archives/」に置く。
1行目: RewriteEngine on は、URLの書き替えができるようにRewrite機能をOnする。
2行目: RewriteBase は書き替えのベースとなるパスを指定する。後述するRewriteRuleは、ここで指定するパスで補完されることになる。なお、3行目のところで説明するが、ドキュメントルートの場合にはRewriteBaseの記述は不要だ。
3行目~6行目: この正規表現がポイント。一番シンプルな6行目を使って説明する。
RewriteRule ^([0-9]+/)([0-9]+/)([^_]+)_([^_]+)\.php$ http://to_example.com/$1/$2/$3-$4/ [NC,R=301,L]
^と$で囲まれた間がリダイレクト元のパターンを表す部分で、^が行頭、$が行末を意味する。()で囲まれている4つそれぞれが後方参照で、()はその選択範囲の境界を明示するもの。このケースでは左から順に$1~$4という後方参照が割り当てられる。
([0-9]+/)は ”一つ以上の0から9の数字列” 、そしてそれに続く"/"を意味するので、「2010/」や「12/」などの年月がここに該当する。
([^_]+)は、"_"(アンダースコア)以外の1文字以上の文字列という意味で、「post」や「123」が該当。
そして、”\.”は、正規表現の特殊文字ではなくて単なるピリオドであるという意味だ。つまりこの6行目は「2010/09/post_123.php」といったリクエストがマッチする。これにRewriteBaseで記述したパス"/"が先頭に補完されるので、「/blog/archives/2010/09/post_123.php」というリクエストに対応することになる。
ここで注意しなければいけないのは、ドキュメントルートである場合だ。「RewriteBase /」などと指定していると、「/」がさらに補完されてしまうので「http://from_example.com//blog/2010/09/post_123.php」というリクエストになってしまう。そのため、ドキュメントルートの場合には RewriteBase の記述は不要である。
リダイレクト先についてはURL全体を記述する。1つ目の後方参照である$1のところには、先に説明した一番最初(左端)の([0-9]+)の部分である「2010」などが入る。$2には左から2番目が、$3は3番目が・・・・といった具合。そして、$3と$4の間にはアンダースコア(_)の代わりに”-”(ハイフン)を挿入している。つまり先のリクエストは、RedirectBaseで補完されていた部分が破棄されて「http://to_example.com/blog/2010/09/post-123/」というリクエストに書き換わる。
最後のオプションは、「NC」でパターンについて大文字・小文字を区別しない(NoCase)、「R=301」で301リダイレクトを指定、「L」は書き換えが行われたら終了 (Last) にするため。現在の書き換え後のURLが後続のルールによってそれ以上書き換えられることを防止するものだ。
ハイフンが複数含まれるリクエストを考慮し、同じ考え方でハイフン4つまでのルールを作成した。
7行目: 同じ考え方で日付アーカイブのパターンにも対応。「/blog/archives/2010/09/」のリクエストは、「http://to_example.com/blog/2010/09/」に書き換わる。
8行目: 前述のパターンに該当しないものは全て、ドメインだけ変えてリダイレクトする。

-------------------------------
もうひとつの、動的クエリを使ったページの301リダイレクトについては、以下のような.htaccessを作成。
[php num=1 font_size="60%"]
RewriteEngine on
RewriteBase /
RewriteCond %{QUERY_STRING} ^id=(.*)$
RewriteRule ^oldblog/index.php$ http://to_example.com/newblog/%1.html? [NC,R=301,L]
[/php]
これで、例えば”http://from_example.com/oldblog/index.php?id=01”というリクエストは、”http://to_example.com/newblog/01.html”にリダイレクトされるようになる。
1行目: RewriteEngine on で、URLの書き替えができるようにRewrite機能をOn
2行目: RewriteBase は書き替えのベースとなるパスを指定
3行目: RewriteCond はクエリ部分のパターンを指定。引数は「id=」とそのまま表記し、(.*)で後方参照とする。
4行目: RewriteRule でパターンにマッチした場合の書き換えルールを指定する。
「^oldblog/index.php$」がリダイレクト元であり、RewriteBaseで指定したパスが自動的に補完されるので、この場合は「http://from_example.com/oldblog/index.php」がリクエストパスとなる。
「http://rightdice.com/newblog/%1.html?」がリダイレクト先であり、URL全体を記載する。「%1」のところにはRewriteCondで処理した後方参照(クエリ部分)である(.*)の内容が入るので。リクエストは「http://rightdice.com/newblog/index.html?id=1」などとなる。そして、最後の「R=301」で301リダイレクトを指定している。

参考:
「URLの書き換え Rewrite」
mod_rewrite URLを書き換えるApacheモジュール
「rewriteモジュールでURLを書き換えろ!」

FC2blogからWordPressへのデータ移行

今回の「MovableTypeからWordPress3.0への移行」と併せ、これまで手付かずでほったらかしてしたFC2blogからのデータ移行もおこなって、WordPressに統合した。fc2blogに残していたのはもうだいぶ前のコンテンツや記事なので、それほど気にしてもいなかったのだけど、せっかくなのでこの機会にWordPressにまとめてしまおう・・・と、気が変わらないうちにさっさとやってしまうことにした。

内容的にはMovableTypeからの移行と変わらない。
・fc2blogのデータバックアップからファイルをダウンロードする。写真も全てダウンロードする。
・秀丸やサクラエディタで画像データのリンクを置換。
・コメントにある”PASS”と”SECRET”の行を削除する。SECRETは 「管理者にだけ表示を許可する・しない」のチェック。PASSにはコメント投稿時のパスが記入されており、削除しないとWPのコメント欄に表示される。
・WordPressの ツール→エクスポートから、ファイルのダウンロードを選択。
といった感じ。
ボクは、MovableTypeの時と同様に、エディタで修正したバックアップデータを、一旦ローカル環境にあるWordPressにインポートし、カテゴリなどの細か部分で修正を加えた後に再度エクスポートした。

WordPressにインポートするとき、画像データなどは先にサーバにアップロードしておく。そうすると、インポートするときにメディアライブラリに自動的に登録されるので便利だ。
あっという間に終わってしまったが、記事も少なかったので手作業でやってもよかったかもしれない(笑)

参考:
fc2ブログからWordPressへ移行

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フィードでお知らせしてくれるので便利だ。

 

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をマルチサイトで使っているユーザーにとって待ちに待ったプラグインなのではないだろうか。。。