全体の参考リンク
WordPressサイトをConoHa VPSに移行しよう｜ConoHa VPSサポート
他サーバーからKUSANAGIへ引っ越す場合の手順 【ダウンタイム最小限】 – たびくも
一番カンタンな移行方法はプラグイン"all-in-one-Migration"の利用
ただし、マルチサイト移行の場合には高額 + 月額課金となるので難しそう。
また、KUSANAGIでall-in-one-migrationを利用する場合、all-in-one-migrationで利用する下記のフォルダ以下ファイルの所有権をPHP実行権を持つオーナーとグループに変更する必要があります。
- wp-content/plugins/all-in-one-wp-migration/storage
- wp-content/ai1wm-backups
具体的には、以下のコマンドを実行。
$ chown -R httpd:www wp-content/plugins/all-in-one-wp-migration/storage
$ chown -R httpd:www wp-content/ai1wm-backups【補足編 〜 KUSANAGI での設定】「ワードプレスをワンクリックで爆速お引っ越し！」その４ 【 All-in-One WP Migration 】 – チラ裏の束
移行前後のPHPバージョンを合わせる
KUSANAGIではアップグレードは比較的容易なようですか、ダウングレードがやややりにくい印象です。
WEBファイルを移行後のWordPressディレクトリにアップロード
私は以下、BackWPupプラグインによって生成されたwebファイル一式とデータベースファイルを利用しました。
wpBackUPプラグインでは、/uploadsフォルダ以下にバックアップファイルがzip形式で生成されます。
リストアさせたいzipファイルをダウンロードし、scpでサーバーへアップロード。
下のコマンドではローカルのデスクトップから、scpでリモートサーバーへアップロードしています。
$ scp ~/Desktop/backupfile.zip username@[サーバのIPアドレス]:/home/kusanagi/xxxxxx/DocumentRootSCPコマンドでローカルのファイルをサーバにアップ＆サーバ上のファイルをDL - Qiita
zipファイルをアップロードできたら、そのままサーバー上で解凍します。
$ unzip backupfile.zip解凍する際、
replace wp-comments-post.php? [y]es, [n]o, [A]ll, [N]one, [r]ename: Aと聞かれるので、A と入力して、既存のファイル・フォルダをすべて置き換えます。
解凍した後の下記ファイルは不要なので、rmコマンドで削除。
・backwpup_readme.txt ・manifest.json ・◯◯◯.pluginlist.□□□.txt ・△△△.sql （本SQLファイルは後で利用するため削除前に保存） ・◯◯◯.wordpress.□□□.txt
《初心者向け》BackWPupの復元方法を画像たっぷりで解説 | 覆面先生（ふくめん）
zipファイルも併せて削除しておきましょう。
つづいて、保存したSQLファイルをphpMyAdminからインポートします。
データベースをインポート
phpMyAdminをインストール
ConoHa VPS, KUSANAGi環境にはphpMyAdminは標準ではインストールされていないので、コマンドラインからインストールします。
$ cd /home/kusanagi/xxxxxxxx/DocumentRoot
$ wget https://files.phpmyadmin.net/phpMyAdmin/4.0.10.20/phpMyAdmin-4.0.10.20-all-languages.zip
$ unzip phpMyAdmin-4.0.10.20-all-languages.zip # 解凍
$ mv phpMyAdmin-4.0.10.20-all-languages phpMyAdmin #リネーム
$ rm phpMyAdmin-4.0.10.20-all-languages.zip # zipファイルを削除KUSANAGIでnginxな環境にphpMyAdminを導入した手順 – SEEKERLOG
インストールしたphpMyAdminは http://【ホスト名】/phpMyAdmin から確認できます。
ログイン情報はユーザーはroot, パスワードはKUSANAGIにログインした際のログイン画面に表示されています。
Nginxの設定を変更
データベースをインポートするために、設定ファイルを変更していきます。
インポートするデータベースファイルのサイズが小さければこのままPHPMyAdminからインポート作業を進めればOK。
しかし、 多くの場合でデータベースファイルサイズが大きいため、SQLファイルインポート時に"413 Request Entity Too Large" というNginxによるエラーメッセージが表示されます。
以下2つのファイルの該当箇所を変更します。
- /etc/nginx/conf.d/xxxxxxx.http.conf
- /etc/nginx/conf.d/xxxxxxx.ssl.conf
それぞれのファイルを、以下のように変更します。
server {
6 listen 80;
7 server_name your-url.com;
8 # 中略
13 client_max_body_size 16M; # 50d0M程度に変更
チェックは３ヵ所！ 413 Request Entity Too Largeが表示された時の対処法 – console dot log
リンク先では
※全サイトに適用する場合は /etc/nginx/nginx.confに設定してもいいようです。
とありますが、上記2ファイルに記述がある場合にはnginx.confの設定よりも優先されるようなので、上記2ファイルの該当箇所を変更するようにしましょう。
変更が完了したら、下記コマンドでNginxを再起動。
# systemctl restart nginxphp.iniの設定を変更
同様に、PHPの側でもファイルサイズに制限がかかっている場合もあるので、php.iniを修正します。
適用されているphp.iniファイルのパスを調べる方法として、phpinfo()を記述したファイルをアップロードする方法があります。
下記コードを記述したphpinfo.phpファイルをドキュメントルート直下にアップロードします。
<?php
phpinfo();URL/phpinfo.phpにアクセスし、下画像の赤枠からパスを得ることができます。
パスが判明したら、phpinfoファイルを残しておくのは危険なのですぐに削除しましょう。
私の場合では、/etc/php7.d/php.ini でした。
該当のパスにあるphp.iniファイルの、下記4つの上限値を変更します。
- post_max_size
- upload_max_filesize
- memory_limit
- max_execution_time
Nginx phpmyadmin sql インポート時のエラー | なんでもDIY
この時、上記の値が以下の関係であることに注意してください。 upload_max_filesize ≦ post_max_size ≦ memory_limit
phpMyAdmin で 504 Gateway Time-out が出たときの対処法 | 株式会社ビヨンド
上記設定の変更が完了したらPHPを再起動させますが、KUSANAGI環境ではphp-fpmを利用しての再起動ではなく、KUSANAGIの再起動によりPHP設定も再起動されるようです。
$ KUSANAGI restart突然php7-fpmが使えなくなりました。 | KUSANAGIユーザーグループ