WordPress環境を引越し、複製、バックアップ、リストアの手順解説

WordPress環境の引越し、複製の手順解説

WordPress環境の引越し、複製の手順解説

まえがき

　
WordPressの環境を引っ越し、複製、バックアップ・復旧（リストア）を行う際の手順書を改めてまとめました。
　
かつて「30分でWordPressを引越し・他のサーバに引越しや開発環境の構築手順」と言う記事でも WordPressの環境を引っ越しするための手順を書きました。
その内容と基本的には変わらないのですが、その後も何度となく環境を移す作業をする中で、こう変えた方がいいな、と思うところがありまして書き直すことにしました。
　
　

WordPress環境の引越しとは？

　
WordPressの環境があります。
それを、

• 開発環境から本番環境にコピーしたい
• 本番環境を開発環境に移したい
• サーバの引越しをしたい
• ドメインを変えたい

といった場合の対応方法について解説をします。
　
　

WordPress環境の引っ越し手順

　
手順は以下の通りです。
　
【手順】

1. 現行サーバにあるファイル一式を取得
2. 現行サーバにあるデータベース一式を取得
3. ファイルの情報を修正
4. データベースの値を変更
5. 新しいサーバにファイルをアップロード
6. 新しいデータベースにデータベースをインポート
7. パーマリンクの空更新
8. 動作確認

１．現行サーバにあるファイル一式を取得

　
まず最初は、現行サーバにあるファイル一式を取得します。
　
サーバにあるファイルを FTPツールですべてダウンロードします。
（ローカル PC内にある環境の場合は単なるフォルダのコピーですね。）
　
初期状態だと 22MBほどですが、アップロードしたファイルが多い場合は時間がかかる場合もあります。
また、日本語ファイル名を付けている場合は、ファイルの文字コードの影響でダウンロードできない場合もありますので、その場合は、ファイルの文字コードを変更しながらやり直しをしてみてください。
　
　
また、「BackWPup」というバックアッププラグインを使ったことがある方は、これを利用してファイル一式を取得する方法もあります。
Zip圧縮した形で取得できますので、ダウンロードの時間が軽減されるので便利ですね。
また、次の項目の「データベース一式を取得」も一緒にできます。
　
BackWPupについては、以下の記事を参考にしてみてください。
　BackWPupでWordPressのDBもファイルもバックアップ
　BackWPupでバックアップ・全体バックアップ具体的設定例
　BackWPupでバックアップ・リストア（復元）の具体的手順
　
　
　

２．現行サーバにあるデータベース一式を取得

　
続いて、現行サーバのデータベース一式を取得します。
　
一般的なレンタルサーバであれば、データベース管理ツール「phpMyAdmin」が利用できると思いますので、それを利用して、WordPressが利用しているテーブルを全てエクスポートします。
　
　

phpMyAdminの画面の「エクスポート」からすべてのテーブルのエクスポートを実施します。
「エクスポート方法」は phpMyAdminのバージョンによって画面のイメージはいろいろありますが、「簡易」で OKです。
「フォーマット」は「SQL」です。
「エンコーディングへの変換」は「なし」です。
ファイルとして保存します。
　
　

データベース一式を取得する前にやっておきたいこと

　
データベース一式を取得すると、リビジョンの情報も取得できます。
長く運用しているサイトではリビジョンの情報の方が多くなっているサイトも少なくありませんので、「Better Delete Revision」というリビジョンを削除するプラグインを使ってリビジョンの情報を削除しておくことをオススメします。
　
「Better Delete Revision」については「Better Delete Revisionを使って WordPressのリビジョンを削除する方法」に記事を書いていますので、参考にしてください。
　
　
　

３．ファイルの情報を修正

　
「１．現行サーバにあるファイル一式を取得」で取得したファイルの情報を新しいサーバのものに変更を行います。
　
修正するファイルは以下の 2ファイルです。
　　/wp-config.php
　　/.htaccess
　
　

/wp-config.php　の変更

バージョン 4.4.2では、下記は 22行目～ 33行目になりますが、データベースへの接続情報が記述されている箇所が対象です。
これを、新しく設置するサーバのデータベース情報に書き換えを行います。
　

/.htaccess　の変更

.htaccessには、パーマリンク設定に関連する情報が記載されています。
新しく設置するサーバの情報に合わせて記載する必要がありますが、間違った設定をすると不具合につながりますので、書き換えをせず削除してしまいます。
　
【変更前】

　
【変更後】

　
「変更前」のようになっている部分を、「変更後」「# BEGIN WordPress」「# END WordPress」だけにしましょう。（「# BEGIN WordPress」「# END WordPress」も消してしまっても構わないのですが。）
ここで記述を削除する .htaccessの内容ですが、新しいサーバに設置した後にパーマリンクを空更新することで自動的に最適な内容で設定されます。
　
※「パーマリンク設定」が「基本」の場合など、WordPressの設定によっては上記の記述がない場合もあります。その場合は .htaccessの対応は不要です。
　
　
　

４．データベースの値を変更

　
「２．現行サーバにあるデータベース一式を取得」で取得した SQLファイルの内容を新しいサーバの情報に書き換えます。
　
環境引越しの作業の中で、この「４．データベースの値を変更」が一番の要であり、一番作業量が大きい手順です。
　
修正するポイントは 2つです。

• URLが記述されている箇所
• ファイルへのパスが記述されている箇所

　
それぞれの修正作業は、テキストエディタで SQLファイルを開いて、置換作業を行っていきます。
ですが、詳細は後述しますが、設定を変更した後文字数も修正する必要な場所もあるため、一括置換で一気に置換をしてしまってはいけません。一つずつ確認しながら置換をします。
　
　

URLが記述されている箇所の置換

　
例えば、ローカル環境から本番環境に移す場合で URLがそれぞれ下記の場合。
　旧環境　　http://localhost:8080/wordpress6
　新環境　　http://example.com
　
ならば、「http://localhost:8080/wordpress6」を「http://example.com」に置換します。
　
　

ファイルへのパスが記述されている箇所の置換

　
例えば、テスト環境から本番環境に移す場合で、「wp-content」までのファイルパスが下記の場合。
　旧環境　　/home/test.example.com/html/wp-content/
　新環境　　/home/www.example.com/htdocs/wp-content/
　
ならば、「/home/test.example.com/html/」を「/home/www.example.com/htdocs/」に置換します。
　
　
では、具体的な修正内容を確認していきます。
　

「WordPress アドレス (URL)」「サイトアドレス (URL)」情報の置換

　
必ず修正を行う必要がある 2カ所は、管理画面のメニューの「設定」－「一般設定」で移動する「一般設定」画面で設定する「WordPress アドレス (URL)」「サイトアドレス (URL)」です。
　
データベースの値としては「wp_options」テーブルにある、「option_name」の項目が「siteurl」「home」の項目で、ここを旧環境の URLから新環境のものに置換します。
　
ちなみに、URLの最後の「/」はないものが標準のようですが、ある、なしはあまり気にしないでよさそうです。
　
　

投稿記事の中にあるサイト内リンクの置換

　
投稿記事内にあるサイト内リンクの URLを旧環境のものから新環境のものに置換を行います。
　
「wp_posts」テーブルが、投稿、固定ページ、カスタム投稿などに投稿した情報を保存しているテーブルです。
「wp_posts」テーブル内の情報は一括置換をしても問題ありませんので、置換する範囲を指定して新しい URLに一括置換します。
　
この「wp_posts」テーブルの中で置換されるのは、記事同士での内部リンクですので、内部リンクが多ければ多いほど置換数が多くなります。
　
ですが、環境が変わっても URLの置換をしなくてもいいようにしておく方法として、内部リンクを関数で処理をする方法があります。
　
具体的には「自サイト内のリンクをショートコードで指定する・アンカーリンク対応版」に記事を書いていますので参考にしてください。
この方法だとリンク先ページのタイトルを変えてもリンク元も自動的に変更されますので運用の効率化にもなりますね。
　
　

wp_options . recently_editedのファイルパスの置換

　
ファイルのパスを置換する必要がある項目の代表例は、「wp_options」テーブルの「option_name」の項目が「recently_edited」というテーブルです。
　
「recently_edited」には、テーマの cssの指定などが書いてあります。
WordPressをインストールした直後などは「recently_edited」の項目がない場合もありますが、ある程度サイトの設定が進んでいる状況であればだいたいは項目が作られていますので、修正をする必要があるでしょう。
　
ただ、ここの項目を修正する際には、レコードの設定方法を少し理解する必要があります。
　
「recently_edited」の行は例えば以下のようになっています。設定によっていろいろな内容が記述されています。
　

　
上記の場合は、「stinger-child」と「stinger」の「style.css」へのパスが記述されています。
そして、前半の「stinger-child」へのパスの↓これで一つの情報になっています。
i:0;s:64:"/home/localhost/htdocs/wp-content/themes/stinger-child/style.css";
　
ここに記述されているパスを変更するわけですが、下記のようにパスが書かれている前の「s:64」の数値がパスが書かれている箇所の文字数になっています。

　
そのため、この「recently_edited」を修正する場合は、パスを修正することとあわせて「s:64」の部分の文字数が編集されている箇所もあわせて修正する必要があります。
ファイルのパスだけ修正してこの文字数を修正しないと不具合の原因になりますので、間違いなく文字数をカウントします。
　
【変更前】
i:0;s:64:"/home/localhost/htdocs/wp-content/themes/stinger-child/style.css";
　
【変更後】
i:0;s:63:"/home/example.com/www/wp-content/themes/stinger-child/style.css";
　
　
このほか、同様に、ファイルのパスが記述されている箇所を検索しながらファイルのパスを書き換えていきます。
先に書いたように、文字数の値もきちんと修正する必要がありますので、一括置換ではなく、検索でパスが記述されている箇所を探しつつ、新しいファイルのパスに置き換えて、文字数をカウントして、文字数の値を修正して．．．と言う作業を、パスが書かれている箇所すべてに対して対応を行います。
　
プラグインをいろいろと活用している方や多くのカスタマイズをしている方は、このファイルのパスと文字数を変更する箇所が多いため、かなり大変な作業になります。
　
ただ、ファイルのパスが書かれている箇所でも文字数をカウントする形式ではない場所もありますので、そこは単純にパスを修正するだけで OKです。
　
　

wp_optionsテーブルの中のテーマ、プラグインの設定変更について

　
サイトの URL、ファイルのパスの変更は、一つずつ検索しながら文字数をカウントしながら置換をしていきますが、「recently_edited」レコード以外の項目を個別具体的な説明を追加します。
　
テーマ「Biz Vektor」を利用している場合
「Biz Vektor」というテーマを利用している場合は、「wp_options」テーブル内に「biz_vektor_theme_options」レコードが作成される場合があります。
ここでは、「Biz Vektor」に設定しているメニューのパスや、メインイメージの画像の URLなどが記述されていますが、この設定も文字数をカウントする仕様になっていますので、ファイルのパス、URLの修正する際には文字数をカウントしながら修正をする必要があります。
　
プラグイン「Announce from the Dashboard」を利用している場合
「Announce from the Dashboard」というプラグインを利用している場合は、「wp_options」テーブル内に「announce_from_the_dashboard」レコードが作成される場合があります。
ここには「Announce from the Dashboard」に関する設定が記述されますが、この設定も文字数をカウントする仕様になっていますので、URLなどが記述されている場合は注意して修正をします。
　
プラグイン「WP Admin UI Customize」を利用している場合
「WP Admin UI Customize」というプラグインを利用している場合は、「wp_options」テーブル内に「wauc_admin_bar_menu_setting」レコードが作成される場合があります。
ここには「WP Admin UI Customize」に関する設定が記述されますが、この設定も文字数をカウントする仕様になっていますので、URLなどが記述されている場合は注意して修正をします。
　
　

「s:64」と文字数を指定する仕組みの

　

　
上記のように文字数をカウントして、その文字数を編集する仕組みがあります。
この仕組みによって、必要な情報を間違いなく取得することができるようになっています。
　
ですが、実は記述されていてもこの機能を使っている処理と使っていない処理が存在します。
　
具体的には、「recently_edited」「wauc_admin_bar_menu_setting」のレコードは、この機能を利用していません。
そのため、文字数を修正していなくても、数え間違っていても何に問題もなく動きます。
　
ですが、「biz_vektor_theme_options」「announce_from_the_dashboard」のレコードは、この機能を利用しています。
そのため、文字数の指定が正しくないと不具合につながります。
　
具体的には、「Biz Vektor」の場合は、設定していたメニューやテーマオプションが設定されていない状態となります。
（管理画面から設定し直せば問題ありませんが、レコード上に古いものは残り続けます。）
　
このような形で、文字数をカウントする仕組みは、プラグイン、テーマによって対応が違いますが、利用されていることを前提で置換していく方がいいでしょう。
　
　

プラグイン「EWWW Image Optimizer」を利用している場合

　
「EWWW Image Optimizer」というプラグインを利用している場合は、「wp_ewwwio_images」というテーブルが作成され、「EWWW Image Optimizer」が作成したファイルのパスが記述されています。
　
ここは、ファイルのパスの文字数を管理してはいませんので、単純に一括置換をすれば問題ありません。
ただ、メディア、テーマとそれぞれ圧縮している場合は、それぞれパスが違いますので、置換漏れがないように置換をしましょう。
　
ちなみに、プラグインで独自のテーブルを持つものとしては、「EWWW Image Optimizer」の他に「BackWPup」などがあります。
独自のテーブルを持っていてもそれはそれで変更する必要がありますので、内容に従って設定を新しいサーバのものに変更を行います。
　
　
一通り置換し終わったら、改めて、違う方法でも検索をしてみて、置換漏れがないかも確認しておきましょう。
　
　
ここまでで変更作業は終了です。
この後は新しい環境の構築作業です。
　
　
　

５．新しいサーバにファイルをアップロード

　
「３．ファイルの情報を修正」で修正したファイル一式を、新しく WordPressを設置するサーバにアップロードします。
　
新しく設置するサーバに FTPで接続し、ファイル一式をアップロードします。
　
このブログの X-Serverは特に問題ありませんが、サーバによっては、パーミッションを変更しないと正常に動作しない場合もあります。
　
　
パーミッションの変更の時、複数のフォルダをいろいろと変更する必要があり、面倒だと思うときは、「パーミッション（属性）一括変更ツール・WordPress最適化済」というツールも作成していますので、試してみてください。
　
　
　

６．新しいデータベースにデータベースをインポート

　
phpMyAdminから「４．データベースの値を変更」で修正した SQLファイルを新しいデータベースに取り込みます。
　
「３．ファイルの情報を修正」で設定したデータベースに、「４．データベースの値を変更」で作成した SQLファイルを取り込みます。
　
データベースはすでに作成してある前提ですが、新しいデータベース作成してもいいですし、既存のデータベースにテーブルを追加する形でも問題ありません。
ただ、既存のデータベースにインポートする場合は、同じ名称のテーブルがないことを確認しておきましょう。
（よく分からない方は、インポートするデータベースに、すでに WordPressが入っている場合は違うデータベースを作りましょう。）
　

　
phpMyAdminの画面で、インポートするデータベースを選択し、「インポート」からファイルを選択し、インポートします。
自動的にテーブルが作成され、データの取込みが終了します。
　
　
　

７．パーマリンクの空更新

　
「３．ファイルの情報を修正」で .htaccessの変更をしていない場合は不要ですが、パーマリンクを空更新することで、新サーバの環境でのパーマリンク設定を行います。
　
手順は簡単で、管理画面の「設定」－「パーマリンク設定」から「パーマリンク設定」の画面に遷移し、特に設定を変更せず「変更を保存」をクリックします。
　
これにより、「３．ファイルの情報を修正」で削除した .htaccessの内容、データベース内のパーマリンク設定が新しいサーバのものに変更されます。
　
　
　

８．動作確認

　
動作確認をします。
　
作業が終わったら、新しいサーバの URLにアクセスし、動作確認をします。
正常に動いていれば問題ありません。
　
　

WordPress引越し時の不具合に関して

　
動作確認を行って、うまく動作しない場合もあります。
不具合が起こる原因は、「３．ファイルの情報を修正」「４．データベースの値を変更」で設定した何かが間違っている場合がほとんどです。
　

リンクが正しくない

　
トップページは正常に表示されるけど、リンクをクリックすると正しくない URLが表示されたり、404 Not Foundになったりする場合があります。
　
これは、「４．データベースの値を変更」の最初に行った「siteurl」「home」の設定が正しくない場合があります。
管理画面の「設定」－「一般設定」の「一般設定」画面に行き「WordPress アドレス (URL)」「サイトアドレス (URL)」の設定が間違っていないか、確認をしてみてください。
　
もしくは、パーマリンクの設定が正しく反映されていない可能性がありますので「７．パーマリンクの空更新」のパーマリンクの空更新を改めて実行してみてください。
　
　

メニューが表示されない・プラグインの動作がおかしい

　
テーマのメニューが表示されない場合や、プラグインが動作しない場合もあります。
　
これは「４．データベースの値を変更」で行った、「ファイルのパスの指定の文字数」の設定が正しく設定されていないことが原因の場合があります。
「４．データベースの値を変更」でも書きましたが、「Biz Vektor」のメニューが表示されないのはこれが原因です。
　
「EWWW Image Optimizer」で処理した画像が表示されないのは、EWWW Image Optimizerは専用のテーブルを持っていますので、その画像のパスが切り替わっていないことが原因の場合が多くあります。
　
データベースの情報を修正する場合は、phpMyAdminで直接修正する方法でも問題ありませんが、修正する項目が多い場合は、「４．データベースの値を変更」の SQLファイルを改めて修正する方法でも問題ありません。
改めてデータベースをインポートする場合は、すでにインポートしたテーブルを一旦削除してからインポートをし直しましょう。
　
　

プラグインが動作しない

　
プラグインがおかしな動きをするのではなく、そもそも動いていなさそうな場合もあります。
　
そういう場合は、プラグインを再設定してみると直る場合が多くあります。
　
具体的には
・「インストール済みプラグイン」のページから該当のプラグインを「停止」→「有効化」を実行してみる
　
それでダメなら
　
・「削除」→「再インストール（新規追加）」を実行してみる
です。
　
　

Duplicatorで全自動引越し

　
長々と解説をしてきましたが、WordPressの環境の引っ越しはプラグインで実行することもできます。
　
「DuplicatorでWordPressを簡単引越し！インストーラー付のバックアップにも」で解説記事を書いていますが、「Duplicator」というプラグインがそれです。
　
若干専門的な知識を必要とし、知らずに適当に使うとデータベースの情報を削除してしまう場合もありますので、一定のデータベースの知識が必要ですが、非常に便利なプラグインですね。
　
こちらも試してみるといいでしょう。