目次

非KUSANAGI環境からKUSANAGI環境へWordPressを移転する方法

旧サーバーで行う作業

Duplicatorプラグインのインストール

移行元となるWordPressにDuplicatorというプラグインをインストールする

Duplicator公式

WP-Optimizeで余分なデータを削除

データの容量が大きすぎると移行に失敗する

WP-Optimizeというプラグインを使うと
投稿のリビジョンなどを一括で削除でき、DBやファイルのサイズを小さくできる

Duplicatorで移行用データの生成

WordPressの管理画面でDuplicatorの画面を開き、新規作成からパッケージを作成

の2つのファイルをダウンロードしておく

xxxxxの部分は日付と英数字の羅列

fullchain.pemとprivkey.pemのダウンロード

cd /etc/letsencrypt/live/example.com
cp fullchain.pem /home/user1/
cp privkey.pem /home/user1/

cd /home/user1/
chmod 777 fullchain.pem
chmod 777 privkey.pem

/etc/letsencrypt/live/example.comのようなディレクトリにある

という2つのファイルをダウンロードする

FTPなどを使ってダウンロードする場合には
直接ダウンロードしようとするとおそらくパーミッションの関係でエラーになるので
ホームディレクトリにコピーを作成して権限を777にしてやる

新サーバーで行う作業1(DNS設定前)

kusanagiのプロビジョニング

kusanagiコマンドを使ってWordPressなどを新規インストールすることをプロビジョニングという

まっさらなWordPressをインストールして
そこに旧環境のDupulicatorで取得したデータを上書きすることで
WordPressを旧環境から新環境に移行する

kusanagi provisionコマンド

kusanagi provision example.com

上記のコマンドでまっさらなWordPressをインストールできる

example.comの部分はkusanagiのプロファイル名

プロファイル名は任意の文字列でいいが、サイトのFQDN(ドメイン名)と一致させておくと管理しやすい

kusanagi provision example.comというコマンドを実行した場合
/home/kusanagiというディレクトリの下に
example.comというディレクトリが作成される

kusanagi provisionの対話処理

実行結果
ターゲットディレクトリは /home/kusanagi/example.com です。
WordPress のインストールで使用する言語を選択してください。
1 : en_US
2 : ja

q : 終了

どれを使用しますか?:  2

ja を選択しました

Webサイトで使用するホスト名(FQDN)を入力してください。 例) kusanagi.tokyo
example.com
Webサイトで使用するホスト名(FQDN)をもう一度入力してください。
example.com

Let's Encryptを使用される場合、Let's Encrypt の使用規約に同意される必要があります。
使用規約に同意される場合、あなたのメールアドレスを入力してください。同意されない場合、Enterキーを二回押してください。
使用規約は次のURLより確認できます: https://letsencrypt.org/repository/

メールアドレスを再入力してください。


データベース名を入力してください。
wp_example
データベース名を再度入力してください。
wp_example

データベース wp_example のユーザー名を入力してください。
wp_example
データベース wp_example のユーザー名を再度入力してください。
wp_example

データベースユーザ'wp_example'のパスワードを入力してください。[a-zA-Z0-9.!#%+_-]の文字列が使用できます。最小は8文字以上です。
再度 'wp_example' のパスワードを入力してください。

(中略)

example.com のプロビジョニングは完了しました。example.com にアクセスし、WordPressをインストールしてください!
完了しました。
言語選択

2(日本語)を選択

FQDN

FQDNを聞かれるので
サイトのドメイン名を入力

ここで書いたFQDNの値がkusanagiの関連ファイルに書き込まれるので
example.comのような仮の値ではなく
旧環境で使用している実際のドメイン名を入力する

Let's Encryptの処理をスキップ

Let's Encryptの規約に同意する場合は
あなたのメールアドレスを入力してください。同意されない場合、Enterキーを二回押してください。
と聞かれるので
Enterを2回押す

新サーバーへ向けたDNSの設定がまだなので、ここでメールアドレスを入力してもLet's Encryptの処理には失敗してしまう

Enterを2回で(規約に同意しないことで)、Let's Encryptの処理をスキップできる

データベース名・データベースユーザー名・パスワード

などと聞かれるので、旧サーバーと同じ情報を入力する

データベース名・ユーザー名・パスワードは
wp-config.phpというファイルを見れば値を確認できる

wp-config.php抜粋
/** WordPress のためのデータベース名 */
define( 'DB_NAME', "xxx" );

/** MySQL データベースのユーザー名 */
define( 'DB_USER', "yyy" );

/** MySQL データベースのパスワード */
define( 'DB_PASSWORD', "xxx" );

ローカルPCでの作業

hostsの設定

C:\Windows\System32\drivers\etcというフォルダにある
hostsファイルを開く

xx.xx.xx.xx   example.com

hostsに上記のような設定を追加する

xx.xx.xx.xxは新サーバーのグローバルIPアドレス
example.comには実際のFQDNを設定

WordPressのインストールウィザード

サイトのトップページへアクセス

ブラウザでhttp://example.com(自分のWordPressのURL)を開く

hostsの効果により新サーバーの方のページが開くはず

まだSSL化はしていないので、httpsだとつながらない
httpでアクセスする点に注意

インストールウィザードの開始

WordPressのインストールウィザードの画面になるので
「さあ、始めましょう !」をクリックして手順を進める

データベース名・ユーザー名・パスワードの設定

などを入力する欄があるので
kusanagi provisionコマンドの対話ウィザードで指定したのと同じ値を入力

の2か所は変更しない

送信

インストール実行をクリック

サイトのタイトルなどを設定

これらの値はDuplicatorによって上書きされるので適当な値を入力していい

WordPressをインストールをクリック

新サーバーで行う作業2(DNSの設定前)

ファイルのアップロード

旧サーバーのDuplicatorで作成した

の2つのファイルを新サーバーにアップロードし
/home/kusanagi/example.com/DocumentRootのようなディレクトリに配置する

example.comの部分は
kusanagi provision example.comのようなコマンドで指定したプロファイル名
(kusanagi provision の後ろに指定した値)

DocumentRoot以下の所有者を確認

cd /home/kusanagi/example.com/DocumentRoot
ls -la
実行結果
drwxrwxrwx.  5 kusanagi kusanagi      4096  5月 22 18:27 .
drwxr-xr-x.  6 kusanagi kusanagi        66  5月 22 18:18 ..
-rw-r--r--.  1 kusanagi kusanagi       669  9月  5  2022 .htaccess
-rw-r--r--.  1 root     root     196246452  5月 22 18:27 20230522_1e697a51e58886e3818be38293e381_fa9b137816b81aab2472_20230522015036_archive.zip
-rw-r--r--.  1 kusanagi kusanagi       405  2月  6  2020 index.php
-rw-r--r--.  1 root     root         75130  5月 22 18:27 installer.php
-rw-r--r--.  1 kusanagi kusanagi     19915  5月 20 16:08 license.txt
-rw-r--r--.  1 kusanagi kusanagi      7402  5月 20 16:08 readme.html
-rw-r--r--.  1 kusanagi kusanagi      7205  9月 17  2022 wp-activate.php
drwxr-xr-x.  9 kusanagi kusanagi      4096  5月 20 20:42 wp-admin
-rw-r--r--.  1 kusanagi kusanagi       351  2月  6  2020 wp-blog-header.php
-rw-r--r--.  1 kusanagi kusanagi      2338 11月 10  2021 wp-comments-post.php
-rw-r--r--.  1 kusanagi kusanagi      3869  9月  5  2022 wp-config-sample.php
-rw-rw-rw-.  1 httpd    www           4199  5月 22 18:22 wp-config.php
drwxrwxrwx.  8 kusanagi kusanagi       182  5月 22 18:24 wp-content
-rw-r--r--.  1 kusanagi kusanagi      5536 11月 24 00:43 wp-cron.php
drwxr-xr-x. 28 kusanagi kusanagi     12288  5月 20 16:09 wp-includes
-rw-r--r--.  1 kusanagi kusanagi      2502 11月 27 06:01 wp-links-opml.php
-rw-r--r--.  1 kusanagi kusanagi      3792  2月 23 19:38 wp-load.php
-rw-r--r--.  1 kusanagi kusanagi     49330  2月 23 19:38 wp-login.php
-rw-r--r--.  1 kusanagi kusanagi      8541  2月  3 22:35 wp-mail.php
-rw-r--r--.  1 kusanagi kusanagi     24993  3月  2 00:05 wp-settings.php
-rw-r--r--.  1 kusanagi kusanagi     34350  9月 17  2022 wp-signup.php
-rw-r--r--.  1 kusanagi kusanagi      4889 11月 24 00:43 wp-trackback.php
-rw-r--r--.  1 kusanagi kusanagi      3238 11月 30 00:51 xmlrpc.php

この3つを除いてファイルの所有者はkusanagi:kusanagiになっている

この状態でDuplicatorのinstaller.phpを使ったリストアを行うと
権限不足によりファイルが書き込めずにリストアに失敗する

nginxの実行ユーザーを確認

vi /etc/nginx/nginx.conf
nginx.conf抜粋
user httpd www;

/etc/nginxディrクトリにある
nginx.confというファイルを開き
user xxx yyy;のような部分を確認する

xxxの部分がユーザー名で、yyyの部分がグループ名

user httpd www;となっている場合は
nginxの実行ユーザーはhttpd:www

DocumentRootの所有者をhttpd:wwwに変更

Duplicatorのinstaller.phpを実行すると
Nginxの権限(httpd:www)でファイルを書き込もうとする

たとえば、wp-contentの所有者はkusanagi:kusanagiとなっているので
httpd:wwwの権限では書き込みができない

よって、旧サーバーから持ってきたデータをリストアできずに
WordPressのデータ移行に失敗する

これを回避するために
Duplicatorのinstaller.phpを実行するときだけ
一時的に全ファイルの所有権をhttpd:wwwに変更する

chown httpd:www -R /home/kusanagi/example.com/DocumentRoot

wp-config.phpとwp-contentをバックアップ

Duplicatorのinstaller.phpを実行したときに
上書きされないように
wp-config.phpとwp-contentをバックアップしておく

mv wp-config.php ../wp-config.php.backup
mv wp-content ../wp-content.backup

名前を変更して、かつ1つ上の階層に移動している

一時的にwp-contentwp-config.phpが存在しない状態になるが
Duplicatorのinstaller.phpを実行すれば
新しいwp-contentwp-config.phpが作成されるので大丈夫

Duplicatorのinstaller.phpを実行

installer.php のページを開く

ブラウザで
http://example.com/installer.php
のようなURLを開く

データベースの情報を入力

Database Connectionのところに

を入力

これはkusanagi provisionのときに設定した
データベース名・データベースユーザー名・パスワードのこと

Validateボタンをクリック

Validateの結果を確認

STATUSのところに
character set and collation isn't supported on current database. “Legacy Character set” and “Legacy Collation” will be replaced with default values.
のように表示され

DETAILSのところに
Character set listutf8mb3Fail
Collations listutf8mb3_general_ciFail
と表示される場合があるが、とりあえずは問題ない

移行元と移行先でMySQLのバージョンが違うことによって発生

utf8mb3のところはutf8
utf8mb3_general_ciのところはutf8_general_ciに置き換えられるが
実質的には同じもの

utf8mb4とutfmb3とutf8の違い

utf8mb4は4バイトの本物のutf8で
utf8mb3は3バイトの疑似的なutf8を意味していて
MySQLのCharacter setでutf8となっている場合は3バイトの疑似的utf8の方なのでutf8mb3と同じ意味

Character set以外にエラーが出ていなければ
I have read and accept all terms & notices*にチェックを入れてNext

リストア結果を確認

Duplicatorのリストアプロセスが走るので、しばらく待つと結果が表示される

実行結果
One or multiple config files were found in main WordPress folders

Config files in WordPress main folders may cause problems with accessing the site after the installation. The following config files were found:

- /home/kusanagi/example.com/DocumentRoot/wp-admin/.htaccess

Please consider removing those files in case you have problems with your site after the installation.

上記のような警告が表示される場合があるが
複数の.htaccessというファイルが存在しているためである

.htaccessはWebサーバーにApacheを使っている場合にアクセス制御をするためのもので
Nginxでの.confファイルに相当する

kusanagi provisionでnginxを使用するように設定した場合
.htaccessは関係ないので警告は無視していい

Duplicator関連のファイルを削除

Auto delete installer files after login to secure site (recommended!)にチェックを入れて
Admin Loginをクリック

ログイン後にこのサイトは正常に移行されました !のような表示があればOK

kusanagiプラグインを手動でコピー

wp-content.backupという名前でバックアップを取っておいたディレクトリから
mu-pluginsを取り出してきて
wp-content/mu-pluginsにコピーする

mu-pluginsにはkusanagiのプラグインが入っている

cd /home/kusanagi/example.com
cp -r wp-content.backup/mu-plugins DocumentRoot/wp-content/

mu-pluginsとは

mu-pluginsのmuはmust useの略

mu-pluginsは必須プラグインのこと

必須プラグインはWordPressの管理画面で無効化できない特殊なプラグイン

旧サーバーのwp-content/mu-pluginsはもともと空のはずで
kusanagi provisionした新サーバーではwp-content/mu-pluginsにkusanagi関連のプラグインが入っている

mu-pluginsの中身を確認

cd /home/kusanagi/example.com/DocumentRoot/wp-content/mu-plugins
ls
実行結果
kusanagi-core  kusanagi-wp-configure.php  wp-kusanagi.php

上記の3ファイルがあればOK

DocumentRootの所有者をkusanagi:kusanagiに変更

chown kusanagi:kusanagi -R /home/kusanagi/example.com/DocumentRoot

Duplicatorのinstaller.phpを実行するために
一時的にhttpd:wwwに変更した所有者を
kusanagi:kusanagiに戻す

プラグインの追加や削除ができない場合の対処方法

ここまでの作業によりWordPressは正常に移行できて順調に動いているように見えるが
WordPressの管理画面からプラグインを追加しようとしても
インストールに失敗しました: ディレクトリを作成できませんでした。
のようなエラーが出る

また、プラグインを削除するときも似たようなエラーになる

これは、WordPressがNginx(httpd:www)の権限でファイルを書き込もうとするが
DocumentRootの所有者はkusanagi:kusanagiになっているために発生する

wp-config.phpの中に書かれている
FS_METHODFTP_USERなどの値を変更すると問題が解決する

wp-config.phpの編集

vi /home/kusanagi/example.com/DocumentRoot/wp-config.php

DocumentRootディレクトリの下の
wp-config.phpを開く

wp-config.php
/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */

#define('WP_ALLOW_MULTISITE', true);
define( 'FORCE_SSL_ADMIN', false);
#define('WP_CACHE', true);

#define('FS_METHOD', 'direct');
#define('FS_METHOD', 'ftpsockets');
define('FS_METHOD', 'ftpext');

define('FTP_HOST', 'localhost');
#define('FTP_HOST', 'localhost:10021');
define('FTP_USER', 'kusanagi');
define('FTP_PASS', 'xxxxx');

/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */
の次の行くらいに

のようなものを書く

xxxxxの部分には実際のパスワードを書く

これでプラグインの追加や削除のときに
kusanagi:kusanagiの権限でファイル操作ができるようになる

WordPressダッシュボードに表示される「セキュリティ状況」の警告へ対処

WordPressの管理画面でダッシュボードを開くと

のような警告が表示されているので、これに対処していく

wp-config.phpをDocumentRootの上に移動

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

WordPressのダッシュボードを確認して
公開ディレクトリにwp-config.phpが存在しています。wp-config.phpをDocumentRootディレクトリの上に移動させて安全性を向上させてください。
という警告が消えて
wp-config.php ファイルの位置は適正です。
という表示に変わっていればOK

wp-config.phpのパーミッションを変更

cd /home/kusanagi/example.com
chmod 440 wp-config.php

WordPressのダッシュボードを確認して
wp-config.php ファイルの権限は 644 です、推奨ファイル権限は 440 です。
という警告が消えて
wp-config.php ファイルの権限は 440 です。
という表示に変わっていればOK

wp-config.phpの所有者を変更

chown kusanagi.www wp-config.php

WordPressのダッシュボードを確認して
wp-config.php ファイルのオーナーは kusanagi.kusanagi です、推奨ファイルオーナーは kusanagi.www です。
という警告が消えて
wp-config.php ファイルのオーナーは kusanagi.www です。
という表示に変わっていればOK

不要なプラグインを削除

サーバーの移行が終わればDuplicatorは不要になる

WordPressの管理画面を開き
プラグインの画面からDuplictorを削除する

wwwのURL正規化

http://www.example.comのようなURLにアクセスしたときに
http://example.comのようなURLにリダイレクトされるように設定する

リダイレクト自体はWordPressがやってくれるが
www付のアドレスが同一のサーバーを示すことをnginxの.confファイルに書いてやる必要がある

xxx_http.confを編集

vi /etc/nginx/conf.d/example.com_http.conf

example.com_http.confのようなファイルを開いて
server_nameの部分にwwwありのドメインを追加する

example.com_http.conf抜粋(変更前)
     server_name example.com;
example.com_http.conf抜粋(変更後)
     server_name example.com www.example.com;

xxx_ssl.confを編集

vi /etc/nginx/conf.d/example.com_ssl.conf

example.com_ssl.confのようなファイルを開いて
server_nameの部分にwwwありのドメインを追加する

example.com_ssl.conf抜粋(変更前)
     server_name  example.com;
example.com_ssl.conf抜粋(変更後)
     server_name  example.com www.example.com;

nginxの再起動

systemctl restart nginx

nginxの.confを編集した後は、nginxサービスの再起動が必要

リダイレクトが機能しているかブラウザから確認

wwwなしとwwwありのURLにアクセスして、どちらもwwwなしのURLに統一されることを確認する

手動でSSL化

DNSの設定前はkusanagi ssl –emailコマンドでサイトをSSL化しようとしても
Let's EncryptのACMEチャレンジに失敗する

旧サーバーから

の2つのファイルを持ってきて
kusanagi ssl --certコマンドでSSL化をすればLet's Encryptの自動更新は機能しないものの
サイトのSSL化自体は可能

DNSの設定が終わってから、別途kusanagi ssl –emailコマンドを実行することで
Let's Encryptの自動更新も機能させる

fullchain.pemとprivkey.pemをアップロード

旧サーバーで事前に取得しておいた

を新サーバーにアップロードする

mv fullchain.pem privkey.pem /home/kusanagi/example.com/

アップロードしたファイルを
/home/kusanagi/example.com/のようなディレクトリに移動

fullchain.pemとprivkey.pemの所有者をkusanagi:kusanagiに変更

cd /home/kusanagi/example.com/
chown kusanagi:kusanagi fullchain.pem
chown kusanagi:kusanagi privkey.pem

fullchain.pemprivkey.pemの所有者をkusanagi:kusanagiに変更する

カレントプロファイルの確認

kusanagi target

kusanagi targetでカレントプロファイルが意図したものになっているか、事前に確認する

意図したものでなかった場合
kusanagi target xxxコマンドでカレントプロファイルを切り替える

xxxの部分はプロファイル名

kusanagi ssl --certコマンドの実行

kusanagi ssl --cert fullchain.pem --key privkey.pem

上記のコマンドを実行することにより
/etc/nginx/conf.dディレクトリの
example.com_ssl.confのようなファイルが書き換えられる

example.com_ssl.conf抜粋(コマンド実行前)
ssl_certificate      /etc/pki/tls/certs/localhost.crt;
ssl_certificate_key  /etc/pki/tls/private/localhost.key;
example.com_ssl.conf抜粋(コマンド実行後)
ssl_certificate      /etc/kusanagi.d/ssl/example.com/fullchain.pem;
ssl_certificate_key  /etc/kusanagi.d/ssl/example.com/privkey.pem;

kusanagi ssl --certコマンドに伴い、nginxの再起動が自動的に発生するので
手動でnginxサービスを再起動する必要はない

不要になったfullchain.pemとprivkey.pemを削除

cd /home/kusanagi/example.com/
rm -f fullchain.pem privkey.pem

kusanagi ssl --certコマンドを実行した時点で
/etc/kusanagi.d/ssl/example.com/のようなディレクトリに
fullchain.pemprivkey.pemはコピーが作成される

よって、元のファイルは削除してOK

httpからhttpsに301リダイレクトさせる

次のコマンドを実行すると、httpからhttpsに301リダイレクトされるようになる

kusanagi https redirect
systemctl restart nginx

上記コマンドを実行すると、具体的には
/etc/nginx/conf.dというディレクトリにある
example.com_http.confのようなファイルが書き換えられる

example.com_http.conf抜粋(編集前)
# rewrite ^(.*)$ https://example.com$uri permanent; # SSL ONLY
example.com_http.conf抜粋(編集後)
rewrite ^(.*)$ https://example.com$uri permanent; # SSL ONLY

httpsへリダイレクトするための設定を
コメントアウトするかしないかの単純な違いだけである

wp-config.phpを編集

cd /home/kusanagi/example.com
vi wp-config.php

wp-config.phpの中に
define( 'WP_SITEURL', 'http://example.com/' );のような記述があったら
ここのURLをhttpsに変更する

define( 'WP_SITEURL', 'http://example.com/' );
define( 'WP_SITEURL', 'https://example.com/' );

WordPressの管理画面からサイトアドレスを確認

WordPressの管理画面で
設定一般 を開く

の2つが、「https、wwwなし」のURLになっているか確認する

WordPress アドレス (URL)の項目は
wp-config.phpdefine( 'WP_SITEURL', 'https://example.com/' );の部分と値が連動している

リダイレクトが機能しているかブラウザから確認

httpとhttps、wwwなしとwwwあり、4パターンのURLにアクセスして
すべてhttps://example.com(https、wwwなし)のURLにリダイレクトされることを確認する

新サーバーでの作業(DNS設定後)

kusanagi ssl --emailコマンドの実行