本ブログをホストしているサーバー業者内でプランをアップデートしたのでWordPressを旧サーバーから新サーバーへ引っ越しをした。旧サーバーのMySQLのバージョンが古かったせいで、ずっとWordPressを3.1からアップデートできない状況だったが、新サーバーに引っ越したら最新バージョン（本エントリの執筆時点では4.0）にようやくアップデートできるようになる。ただし、今回はサーバー移転がメインなので、WordPress自体は同じバージョンのまま移行。
WordPressの引っ越しの手順はググればいくらでも見つかるが、
- 旧サーバーでMySQLのバックアップ
- 旧サーバーでWordPressのバックアップ
- MySQLのバックアップファイルを調整
- WordPressのバックアップファイルを調整
- 新サーバーでMySQLのリストア
- 新サーバーでWordPressのリストア
というのが大まかな流れ。
今回の引っ越しのポイントとしては
- ブログのURLは同じ
- WordPressがインストールされている物理パスが変わる
という2点。
共用サーバーを使っていると、ホームディレクトリのパスはサーバー業者に割り当てられてしまう宿命なので、2点目のWordPressのインストールパスが変わるというのはよくあることだろう。新旧サーバーで同じホームディレクトリだったら簡単なんだけどねぇ。
ここでは新旧サーバーでのWordPressのインストールパスを
- 旧サーバー：
/home/before/public_html/wordpress - 新サーバー：
/home/after/public_html/wordpress
と仮定しましょう。
MySQLのバックアップファイル（mysqldumpで出力されたSQLスクリプト）には、データの一部に物理パスが含まれているので、そいつらを手で全部書き換えてやらなきゃいけない。最初は単純な文字列置換だからsedで一括変換すればいいやと思ってたんだけど、いざリストアしてみるとプラグインのいくつかが動かなくなりハマったわけ。
改めてバックアップしたSQLスクリプトから物理パスを抽出してみると、物理パスが書かれているのはすべてwp_optionsテーブルの中で、
s:83:\"/home/before/public_html/wordpress/wp-content/plugins/wp-dbmanager/wp-dbmanager.php\"
というレコードになっていた。
このs:83って部分が何を意味するのかわからなかったけど、後続の文字列数を数えてみると83文字！他にもi:4とかa:2とかがあるところを見ると、文字列はs:文字列長:"値"、数値はi:値、配列はa:要素数:{値}というルールっぽい。たぶん、WordPressのAPIがシリアライズしてくれてるんだな。
つまり、物理パスを書き換える場合、単純な文字列置換だけじゃなく文字列長を正しく調整する必要があると。新旧サーバーで物理パスの文字列の差分は「before」と「after」で、文字列長は1つ減ることになる。
前述のレコードだと
s:82:\"/home/after/public_html/wordpress/wp-content/plugins/wp-dbmanager/wp-dbmanager.php\"
と書き換えてやればいいわけだ。
コマンドで一括変換できないかとも思ったが、この形式でデータを保存しているプラグインの数が少なかったので、エディタでちまちま調整していった。
WordPressがMySQLに保存する物理パスをインストールパスからの相対パスになるように設計されていれば、こんな面倒なことはしなくて済むんだけど、これだけ世界中で使われているソフトだと現実的に途中で仕様変更はできないんだろうな。