ConoHa VPS(KUSANAGI)にWordPressを移行させる手順と方法

Last Edited Time
Nov 4, 2021 10:39 AM
Category
WordPress
Not yet (Unpublish)
Podcast
Super Published
Tag Library

全体の参考リンク

image

一番カンタンな移行方法はプラグイン"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

移行前後のPHPバージョンを合わせる

KUSANAGIではアップグレードは比較的容易なようですか、ダウングレードがやややりにくい印象です。

WEBファイルを移行後のWordPressディレクトリにアップロード

私は以下、BackWPupプラグインによって生成されたwebファイル一式とデータベースファイルを利用しました。

wpBackUPプラグインでは、/uploadsフォルダ以下にバックアップファイルがzip形式で生成されます。

リストアさせたいzipファイルをダウンロードし、scpでサーバーへアップロード。

下のコマンドではローカルのデスクトップから、scpでリモートサーバーへアップロードしています。

$ scp ~/Desktop/backupfile.zip [email protected][サーバのIPアドレス]:/home/kusanagi/xxxxxx/DocumentRoot

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

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ファイルを削除

インストールした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程度に変更

リンク先では

※全サイトに適用する場合は /etc/nginx/nginx.confに設定してもいいようです。

とありますが、上記2ファイルに記述がある場合にはnginx.confの設定よりも優先されるようなので、上記2ファイルの該当箇所を変更するようにしましょう。

変更が完了したら、下記コマンドでNginxを再起動。

# systemctl restart nginx

php.iniの設定を変更

同様に、PHPの側でもファイルサイズに制限がかかっている場合もあるので、php.iniを修正します。

適用されているphp.iniファイルのパスを調べる方法として、phpinfo()を記述したファイルをアップロードする方法があります。

下記コードを記述したphpinfo.phpファイルをドキュメントルート直下にアップロードします。

<?php
phpinfo();

URL/phpinfo.phpにアクセスし、下画像の赤枠からパスを得ることができます。

image

パスが判明したら、phpinfoファイルを残しておくのは危険なのですぐに削除しましょう。

私の場合では、/etc/php7.d/php.ini でした。

該当のパスにあるphp.iniファイルの、下記4つの上限値を変更します。

  • post_max_size
  • upload_max_filesize
  • memory_limit
  • max_execution_time
この時、上記の値が以下の関係であることに注意してください。 upload_max_filesize ≦ post_max_size ≦ memory_limit

上記設定の変更が完了したらPHPを再起動させますが、KUSANAGI環境ではphp-fpmを利用しての再起動ではなく、KUSANAGIの再起動によりPHP設定も再起動されるようです。

$ KUSANAGI restart

URLの変更がある場合、URL変更の設定を行う