HTTPで稼働しているWordPressサイトを「常時SSL、HTTP/2化」する方法（準備編）：とにかく速いWordPress（15）（2/3 ページ）

[中村けん牛，プライム・ストラテジー]

4：移行先のKUSANAGI環境で、移行元のWordPressサイト（HTTP）を再現する

　移行先となるKUSANAGI環境のコンソールで転送されたファイルを展開します。管理者ユーザーで実行します。

cd /home/kusanagi/
tar zxvfp www.tar.gz

KUSANAGI環境で転送したファイルを展開する

　続いて、データベースのインポート、展開したファイルの配置、wp-config.phpの修正、WordPressのアップデートとKUSANAGI専用プラグインのインストール、オーナーとパーミッションの設定、管理画面へのログインの作業を順に進めていきます。

5：データベースのインポート

　KUSANAGIはInnoDBストレージエンジンに最適化されています。移行元がMyISAMストレージエンジンを利用していた場合には、ここでダンプファイルのテーブルスキーマを書き換えておきます。以下のように、展開したファイル群の中にあるexample.sqlの「ENGINE=MyISAM」となっている部分を「ENGINE=InnoDB」に置換するとよいでしょう。

cd /home/kusanagi/www
sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' example.sql > example.InnoDB.sql

ダンプファイルのテーブルスキーマを書き換える（移行元がMyISAMストレージエンジンを利用していた場合）

　データベースをインポートします。

mysql -u example -p -h localhost example < example.InnoDB.sql

データベースをインポートする

　インポートしたデータベースのテーブル状況が正しいかを確認します。

mysql -u example -p -h localhost example -e 'show table status'

データベースが正しくインポートされたかを確認

　Engineフィールドが「InnoDB」になっていれば正しくインポートできています。

6：展開したファイルを配置する

　まず、KUSANAGIのプロビジョニングで配置されたデフォルトのドキュメントルートを一時的に待避して、後ほど利用できるようにしておきます。

cd /home/kusanagi/example.com
mv DocumentRoot DocumentRoot.def

デフォルトのドキュメントルートを一時的に待避する

　先ほど展開したファイルを配置します。移行元のドキュメントルートであったhtmlディレクトリを、移行先であるKUSANAGIのプロビジョニングで配置されたDocumentRootディレクトリと同じ位置、ディレクトリ名となるように移動します。

mv /home/kusanagi/www/html /home/kusanagi/example.com/DocumentRoot

KUSANAGI環境でのDocumentRootディレクトリに配置する

　「wp-config.php」をドキュメントルートの1つ上の階層に移動させます。

cd /home/kusanagi/example.com/DocumentRoot
mv wp-config.php ../

「wp-config.php」を1つ上の階層に移動する

7：「wp-config.php」の内容を修正する

　移動した「wp-config.php」の内容を書き換えます。まず、データベース情報の一部をKUSANAGIのプロビジョニング時に設定した内容に修正します。

/** MySQL データベースのユーザー名 */
define('DB_USER', 'exampleuser');
/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'Password123!');

「wp-config.php」の内容を書き換える（1）

　もしWP_CACHE定数が定義されていなかった場合は、wp-config.phpの最終行付近にある「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」の上に、以下の文字列を追加します。

define('WP_CACHE', false);

「wp-config.php」の最終行付近に追加する

　最後に、移行元で「WP SiteManager」プラグインを利用していた場合には、KUSANAGI専用プラグインと一部機能が重複することから、以下の定数を「WP_CACHE定数定義の前後」に定義して、ページキャッシュとデバイス切り替えの機能はKUSANAGI専用プラグインを利用するように設定します。

define('WPSM_DISABLE_CACHE', true);
define('WPSM_DISABLE_DEVICE', true);

KUSANAGI専用プラグインを利用するようにする定数を挿入しておく

　以上で、WordPressが動作する最低限の環境が整いました。ブラウザでKUSANAGI環境のWordPressサイトへアクセスして、正しく機能しているかを確認してください。

　うまく動作しない場合は、wp-config.phpのWP_DEBUG定数を「true」に定義して、表示されるエラーメッセージの内容およびサーバのログ（/home/kusanagi/example.com/log以下および/var/log以下）を確認してみてください。例えば、移行元で使っていたプラグインなどがHHVM、PHP 7などに対応していない場合が挙げられます。KUSANAGIでは、以下のコマンドでPHP実行環境をPHP 7、HHVM（HipHop Virtual Machine）、PHP 5.6に切り替えられるので、言語環境固有の問題かどうかを切り分けてみるとよいでしょう。

kusanagi php7

PHP実行環境をPHP 7へ切り替えるコマンド

kusanagi hhvm

HHVMへ切り替えるコマンド

kusanagi php-fpm

PHP 5.6へ切り替えるコマンド

8：WordPressのアップデートとKUSANAGI専用プラグインのインストール

　動作確認ができたら、手順（6）で退避しておいた「DocumentRoot.defディレクトリの中身」をDocumentRootディレクトリ内に上書きします。DocumentRoot.defディレクトリの中には最新版のWordPressコア、KUSANAGI専用プラグイン、.htaccessなどの制御ファイルが含まれています。これをDocumentRoootディレクトリ内に上書きすることによりWordPressが最新版にアップデートされ、併せて、KUSANAGI専用プラグインがインストールされます。

cd /home/kusanagi/example.com/DocumentRoot.def
/bin/cp -rp * ../DocumentRoot/

退避しておいた「DocumentRoot.defディレクトリの中身」をDocumentRootディレクトリ内に上書きする

　ここで、再度ブラウザでWordPressサイトへアクセスし、動作を確認しておきましょう。