サイトの引っ越し作業
反応がひどく遅くなったレンタルサーバーから高性能レンタルサーバーに乗り替えたいとの相談を受け、一番評判の良いXserverへの引っ越しを提案し、引っ越し作業を手伝うことになりました。（2020年6月から7月にかけて）
私自身は月500円レベルのさくらインターネットのスタンダードやロリポップのスタンダードには触れていますが、月1000円レベルのサーバーは経験がありませんでした。
Xserverの印象
Xserverは評判通りでした。マニュアルが整っており、サーバーパネルがよく整理されていて、シンプルで必要十分に作られていました。
Xserverには、コントロールパネル上で受信メールを一覧できるウェブメールがありません。また、さくらインターネットの場合、提供される60種類のドメインから好な名前を選んでそのサブドメインを無料で利用できますが、Xserverでは独自ドメイン以外に使えるのは規定の一つだけです。
しかし、これらは多くの場合無くても困らない機能です。
新サーバへの移行の事前確認法
引っ越しの際、まだ以前のサーバーが有効な内に、データを新サーバーにコピーします。その移行作業がうまくいっていることを確認してから最後に移行する（ドメインネームサーバーを切り替える）ようにしたいのですが、それをどう実現するかが問題と思っていました。
どのサーバーに対しても使えて汎用性がある「自分のPCのhostsファイルを書き替える方法」がその答えでした。
Xserverの場合、他社で管理されているドメインを、ネームサーバーを切替える前にサイト内容を確認できる「動作確認URL」を発行できるのですが、これは余り役に立ちません。
abcd.com というドメインのサイトに対し、動作確認アドレスhttp://abcd-com.check-xserver.jp/ をつくることができますが、サブドメインには対応していません。また、WordPress等の一部のプログラムでは、動作確認URL機能による動作確認が正常にできない場合があるとのこと。
結局、自分のPCのhostsファイルに書き足して、そのPCからのアクセスに限りURLを引っ越し後のIPアドレスに強制的に割り当ててしまう方法を使う方が確実です。もっぱらこの方法を使いました。
XserverのFTPは、DNSサーバーの切り替えの影響を受けないFTPサーバー名 sv***.xserver.jp（sv***はサーバ番号）ですが、移行前のレンタルサーバーのFTPサーバーの名称はftp.xxx.jp（xxx.jpは独自ドメイン名）でした。この場合、DNSサーバーを新しいものに切り替えると、FileZilla等のFTPクライアントソフトで旧FTPサーバーにアクセスできなくなりました。旧サイトのFTPサーバーに接続するには、hostsファイルで旧IPアドレスとftp.xxx.jpを紐付けることが必要でした。
ドメインとサブドメイン
独自ドメインabcd.jp（仮名）を登録するとhttp://abcd.jpでもhttp://www.abcd.jpでもアクセスできる様になるのが普通です。
同様にサブドメインxyz（仮名）を追加登録したとき、http://xyz.abcd.jpでもhttp://www.xyz.abcd.jpもアクセスできるようになるのかと思いましたが、そうではありません。
- http://www.abcd.jpのwwwもサブドメインの一種です。
- xyzとwww.xyzはそれぞれ別個のサブドメインです。
- xyzというサブドメインに対しwww.xyzというサブドメインが自動的に作られることはなく、使うならそれぞれ登録が必要でした。
独自ドメインがwww. 付きでもアクセスできるのはDNSレコードにあらかじめ指定しているからでした。
Xserverの場合、DNSレコードのAレコードタイプでabcd.jpとwww.abcd.jpの両方をレンタルサーバのIPアドレス123.145.67.89（仮の数字）に対応づけていました。
移行前のサーバーではXserverと違い、www.abcd.jpをDNSレコードのCNAMEレコードタイプでabcd.jpの別名として定義していました。（どちらでも同じ作用をするようです。）
www有りと無しのどちらでもアクセス可にしても、SEO的にはアクセス先のURLはwww有りか無しか一方に .htaccessファイルで統一するのが良策だとのこと。
WordPressの引っ越しはAll-in-One WP Migrationプラグインが便利
Xserverの「WordPress簡単移行」でうまくいかなかったWordPressの引っ越しが、プラグインのAll-in-One WP Migration（以下A1WMと略す）ではすんなり成功し、使わない手はないと思いました。
A1WMを使うには、
- 移行先にWPをインストールすることが必要です。
- 引っ越し元のWPにA1WMをインストールして、エクスポートします。エクスポートで作成されるファイルサイズには制限が無いようですが、移行先にインポートする際に、無料版では500MB以上のファイルを処理できません。
- 移行先のWPにもA1WMをインストールしてエクスポートしたファイルをインポートします。このインポートするファイルが100MB以上有る場合はインポートの際警告が出るので、指示に従って拡張プラグインall-in-one-wp-migration-file-extension.zipをダウンロード・インストールし、500MBまで処理できるように拡張します。
all-in-one-wp-migration-file-extension.zipをプラグインとしてアップロードし有効化します。
プラグインのAll-in-One WP Migration（とAll-in-One WP Migration File Extention）を使った印象は、
動作が速いこと、無料版でも拡張機能を使えば、ファイルサイズ制限を500MBまで緩められること、容量の多いメディアデータ（wp-contentの中のuploadsにまとめられている）などを「高度なオプション」で簡単に除いてファイルサイズを小さく出来ることなど、柔軟性があります。
ベーシック機能のファイルサイズ制限がバージョンによっていろいろ変わる（後述）気まぐれっぽいところが気になりますが、とにかく便利で試してみる価値があります。
データベースの接頭語（プレフィックス）を移行先のデータベースに合わせて自動変換してくれます。
6月11日の時点のバージョン7.23では、マルチバイトコンバートエンコーディングに問題があり、2つ目のWPの移行では下記のような警告が出ました。
（この警告は、phpMyAdminでデータベースのデータを手動エクスポートしたsqlファイルを移行先のデータベースにインポートし、wp-config.phpファイルのプレフィックス指定を移行元の値に変えたら、出なくなりました。
どうやらwordpressファイルに圧縮し、インポート時に展開する過程でmultibyteコードの処理を誤ることがあるらしく、手動でエクスポート・インポートするときは圧縮解凍過程がないので修正されたようです。 尚、プラグインの「WP Multibyte Patch」も有効化しています。）
6月22日には7.24バージョンアップされ警告が出なくなりました。その一方、7.23ではファイルサイズが163MBでも無料版A1WMだけで処理出来ましたが、7.24では50MBで制限の警告が出ました。現在最新の7.25では、100MBで警告が出ますが、いずれにせよall-in-one-wp-migration-file-extension.zipを追加すれば512MBまで扱えるようになります。
