これで文字化けも回避！ Movable Typeサーバ移行と統合あれこれ

どうも、年上のほうのY.Kです。
ここ3カ月ほど、Movable Type（以下MT）のサーバ移行案件が続きました。
特に、古いレンタルサーバプランが突然新サーバに移行するという事案がありました。
それぞれの移行で発生した問題点や解決方法をまとめておきます。

基本的に、弊社としてはWordpressを利用していなかった頃の案件です。
とはいえ、MT3からの移行に利用した『最終手段』はWordpressでも有効なはずです。
少々（？）長いですが、ＷＰ派の皆さんもぜひ最後までお読みください。

移行元も移行先も比較的新しい同じバージョンで統一できている場合は、標準の機能を使いましょう。
ウェブサイト単位で「バックアップ」した圧縮ファイルを「復元」からアップロードすればオッケーです。

ところで、先にDNSを移行する必要がある場合など、とりあえずファイルをアップしている事って結構ありますよね？(*)
この場合、圧縮されているとはいえバックアップファイル内の同じ画像を上げなおすのは二度手間です。

圧縮ファイルの中を見てみましょう。
バックアップファイルの中身については、圧縮なしでバックアップした場合の公式Q&Aページに詳しく説明されています。
画像以外には、「*.manifest」と「*.xml」の2種類のファイルがあります。
データ量によっては「*.xml」ファイルが分割されていたりします。

「*.manifest」ファイルを見てみると、xml宣言こそないものの、xml形式でファイルの情報が記述されていることが分かります。
（あまり詳しくないのですが、WindowsXPで導入されたマニフェストファイルの親戚でしょうか）

<manifest xmlns='http://www.sixapart.com/ns/movabletype'>
<file type='backup' name='Movable_Type-2014-02-19-10-37-13-Backup-1.xml' />
<file type='asset' name='iharasamaimg.jpg' asset_id='5365' />
・
・
・

そして、「*.xml」ファイルをよく確認すると、アイテムを特定する「asset_id」とファイルのURLやサーバパスが書かれています。
テキストエディタでサーバパスを新サーバの状態に置換して、まずこのファイルだけを「復元」してみました。
一部、カスタムフィールドの設定がおかしくなっていましたが、ほぼほぼうまくいきました。
この方法で問題ないようです。

(*)どちらかのサーバにsshで入れるのであれば、ファイル移行はできればサーバ内から作業しましょう。
普段はWindowsユーザの人でも、「ファイル名の文字コード」や「大文字小文字の重複に対応していない」といった問題を意識せずにすみます。
特にlftpは以下のようにミラーリング処理などをサポートしており、とっても楽でオススメです。
http://hooktail.org/computer/index.php?lftp#content_1_8

2つのMT5それぞれに結構な数のウェブサイトを構築しているお客様について、すこしずつMT6のサーバに移行することになりました。
片方のMTを先に全て移動することができればまだ楽なのですが、スケジュールの都合でそうはいきませんでした。
また、各ブログについてカスタムフィールドが設定されています。
困ったら、まずプラグインを探しましょう。

見つかりました。

いつもお世話になっているサイトの一つ、小粋空間さんです。
http://www.koikikukan.com/archives/2011/12/29-015555.php

上記ページにあるように、テーマをエクスポートしてインポートするだけです。
ウェブサイト／ブログを作成する時には必ずテーマを選択します。
テーマをアップするだけなのでインポート時の作業はあまり変わりません。
オススメです。

上記説明では、アイテムとカスタムフィールドを先にインポートしています。
今回の案件は、ウェブページはMT管理下に置いていない編成だったこともあり、記事数によっては一緒にエクスポート／インポートしてもほぼ問題ありませんでした。
MT6対応についても特に触れられていませんが、今回は問題ありませんでした。

ただし、EntryImExporterプラグイン、PageImExporterプラグインは商用利用は有料です。
移行先だけでなく、移行元にもライセンスが発生するので特に注意が必要です。
それでも、記事の量によっては購入する価値は十分にあります。

さて、問題のMT3で構築した古～いサイトです。
サーバ会社がデータベースを移行してくれています！
とっても親切！　早速MTでアクセスです。

文字化け！

MT3からMT5への移行はさすがに危険です……
でも、有償のMT4は手に入りませんが、MTOSなら手に入ります！
https://movabletype.org/downloads/archives/
そもそもMT3の時代はカスタムフィールドがなかったので、移行の第一段階としてはMTOSで十分です。
MTOS4の最終版を使用することにしましょう。
「4.x/」を開いて一番下までスクロールし、「MTOS-4.381-ja.tar.gz」または「MTOS-4.381-ja.zip」をダウンロードします。

新サーバにMTOS4を入れて、アップグレード！

やっぱり文字化け！
DBの設定と実際の文字コードに差異があるようです。
何とかしてみましょう！

早速旧サーバに戻ってphpMyAdminにログイン……505エラー？
もっともこれはphp.iniを削除したら解決し、ログイン画面が表示されました。

……でも、なんだかバージョンが新しすぎる気がします。
とりあえずログインしてみましょう。

「INFORMATION_SCHEMAが見つかりません」？
……MySQL４にはありませんでしたね。
サーバ側がセキュリティを考慮してphpMyAdmin側だけバージョンを上げてくれたのですが……

DBをアップグレードしたり、古いphpMyAdminを入れることもできます。
しかし、もう使わないサーバに対してはちょっと大げさです。

「Adminer」は「adminer.php」1ファイルでDBを操作できるphpです。
minifyされていたり、読めない圧縮コードが含まれていますが、それを考えてもかなり小さいです。
ある程度DBが操作できる人には必要十分な機能がそろっています。
とにかく、phpMyAdminをごっそり入れるよりはだいぶ軽いです。
……というのはすでにいろいろな皆さんが紹介されています。

中でも以下の記事は、拡張方法についても触れているので参考になりました。
phpMyAdminで困ったらAdminerを使え！ その2

「adminer.php」で元のDBのテーブル、データを全てエクスポートします。
ちゃんとUTF-8でSQLファイルが出力されます。

試しにDBを複製して、旧サーバにMTOS4を入れてアップグレード！

やっぱり文字化けです。

うーん、Perlで文字化けということは……Encode.pmが正しく動いていないのでしょうか？ UseJcodeModuleを設定してみましょう。
DBの中にない文字も文字化けしています！
どうやらjcode.pmも使えない古いPerlだったようです。
サーバ会社によるデータ移行が失敗したのもこれが原因でしょうか。

エクスポートしたSQLファイルを確認してみましょう。
CREATE文に「CHARSET=ujis」とあります。今回はEUC-JPですね。
これを全て「CHARSET=utf8」に置換した状態で新サーバにインポートしましょう。
ファイルが大きい場合は「gzip」形式で圧縮してからアップします。
それでも大きい場合は分割していくしかありません。

さて、新サーバでMTが利用できるようになりました。
通常のサーバ移行のときにも行なうチェックを進めていきましょう。

• プラグインの入れ忘れはないでしょうか？　新しいバージョンでも動くでしょうか？
• 逆に新バージョンに統合されて不要になったプラグインはあるでしょうか？
• 検索などで、スクリプトへのパスや各種ＩＤを直接指定しているところはないでしょうか？

もちろん、セキュリティのためにはもっと新しいバージョンにしておく必要もありますね。