カテゴリー
WordPressプラグイン

Duplicatorプラグインの複製でサイト移設、検証環境を作る

WordPressはセキュリティの観点からも最新の状態に保つ必要があります。
しかし、バージョンアップによってプラグインやテーマ、またはPHPなどのサーバ仕様が原因で正常に表示できなくなるケースも見受けられます。
とくにメジャーバージョンアップの際はこれらのリスクが非常に高くなります。
では、どうすればよいか?
これを防ぐには事前に動作の検証確認を行うこと。

今回は本番同様のテストを行うためのいわゆるステージングサーバのようにも使える、既存サイトの複製方法を紹介します。

複製サイトの構築

検証環境といえば、ローカル環境の構築をイメージされる方も多いと思います。
しかし、OSによってやり方は異なりますし、PCが得意でなければここで挫折してしまうでしょう。
もっとも手軽な方法はサーバ内にもうひとつWordPressをインストールすること。
つまり、サブディレクトリやサブドメインにサイトを複製することです。

WordPressの複製に必要なバックアップファイル

静的HTMLサイトであれば、基本的にサーバ内のファイルが構成データのすべてです。
しかし、WordPressで構築されたサイトはそうではありません。
サーバ内には下記のファイルが格納されています。

  1. WordPressプログラム本体
  2. デザイン&機能(テーマ)
  3. 追加機能(プラグイン)
  4. 投稿に使用される画像などメディアファイル

そして、実際の投稿データと各種設定データはデータベースに保存されています。
移設や複製にはこの2つが必要となります。

例えば、実際のサイトがexample.comで検証のための複製先がサブドメインのexample.com/proto-site/だとします。
手動でサイトを複製する場合はいわゆるFTPで確認できるサーバ内のファイルをすべてproto-siteにコピーします。
加えてデータベースの複製が必要となるのですが、このケースではサブディレクト配下になるため、URLが変わります。
データベース内のURLをすべて書き換える必要がありますが、この中にはシリアライズという内容が含まれており、単純に一括で置き換えればよいというわけではありません。

WordPressにそれなりに精通していれば、これらの作業はさほど難しくないのですが、やはり少々敷居が高い感じられる方も多いでしょう。
ここからはWordPressサイトの移設・複製を簡単に行える「Duplicator」というプラグインを使用したWordPressの複製を解説します。

Duplicatorプラグインの使い方

事前準備

検証用WordPress用のデータベースを作成します。
既存のデータベースに加えるのではなく、必ず新規のデータベースを生成ください。
Duplicatorで複製の際にデータベース情報が必要となります。

  1. データベース名
  2. MySQLデータベースのユーザー名
  3. MySQLデータベースのパスワード
  4. MySQLのホスト名

※この記事では同一ドメイン内での検証環境の作成を想定していますが、異なるサーバへの移設の際は新サーバで行う作業となります。

データベースの作成方法が分からない場合

レンタルサーバの「自動インストール」などでサブディレクトリなどに新規のWordPressインストールしてそのデータベースを使用します。

例えば、元のドメインがexample.comであった場合にexample.com/proto-site/にインストールします。
そのwp-config.phpより上記のデータベース情報を控えます。
その上でwp-config.phpを含めてインストールしたWordPressは削除してしまいます。(proto-siteディレクトリを空にする)
つまり、データベースだけを使用するということです。

※インストーラの実行の際に上書きされるだけなので、ほとんどの場合で削除しなくても問題ありません。

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

新規追加より「Duplicator WordPress Migration Plugin」で検索してインストール、有効化します。
Duplicatorのinstall

セッティング

Duplicatorメニューsettings→GeneralタブのStorage項目で「Disable .htaccess File In Storage Directory Disable if issues occur when downloading installer/archive files.」をチェックします。(バックアップフォルダに.htaccessを生成が原因で処理がエラーとなるケースがあるため、対処しておきます。)
Duplicatorのセッティング

バックアップデータの作成

それでは複製データを作りましょう。
Packages→右のCreate Newタブをクリックします。
以下のような画面になりますので、分かりやすい名称を入力して、Nextで進みます。
新しいバックアップを作成

バックアップデータのチェックが行われます。
緑の「Good」であれば問題ありませんので、「Yes. Continue with the build process!」をチェックしてBuildへ進みます。
バックアップデータの確認

もし、「Notice」が表示された場合は内容をチェックします。
下記はよくあるパターンの警告ですが、実際には問題なく完了するケースも多いので、まずはそのまま作成してみることをお勧めします。

Size Checks
タイムアウトする場合があるというファイルサイズについての警告です。
→チェックして複製対象から外し、手動でコピーする。

Addun Sites
サブディレクトリの中に別のWordPressがあるということです。
→Quick Filtersでチェックして除外します。

Name Checks
ファイル名に特殊文字が含まれるという警告です。
→画像名などに不適切な文字が使われているようなケースです。これは無視して進んで、問題があれば、複製後に修正するのが現実的かと思います。

容量による警告

これでバックアップデータが生成されます。
複製先にコピーするinstaller(installer.php)とArchive(名称+data_xxxxx.zip)の2つをクリックしてダウンロードします。バックアップ完了

バックアップデータ

複製サイトでの復元

先にインストール済みの複製先WordPressフォルダにダウンロードしたバックアップファイル2つをアップロードします。
この際にセキュリティの観点からサブディレクトリへインストールが推奨されています。
example.com/proto-siteのような形です。

そして、検証サイトのURLにinstaller.phpを付与してアクセスします。
上記であれば、example.com/proto-site/installer.phpとなります。

下記の赤NoticeはWordPressのルート階層へバックアップデータをアップロードしているために警告が表示されています。(実際の復元には支障はありません)
複製開始

事前準備で確認した複製用のWordPressのデータベース情報を入力します。

データベース情報に間違いがなければ、新しい複製サイトの情報が表示されますので、「Next」で実行します。複製確認最後に複製したサイトにログインし、DuplicatorのTools→「Data Cleanup」実行すると、先にコピーした2つは削除されます。複製データの削除

以下はDuplicatorで生成される可能性のあるファイル一覧です。
サーバ内を確認しこれらが残っている場合は削除しましょう。

wp-snapshots
installer.php
installer-backup.php
dup-installer-data_xxxxx.sql
dup-database_xxxxx.sql
dup-installer-log_xxxxx.txt
xxxxx _archive.zip
htaccess.xxxxx.orig

実はこの「Duplicator」は重大な脆弱性が発見されたことがあります。
もちろん、現在は対処済みでそれだけ多く使われているということでしょう。
いずれにしても、サーバ内にデータベースを書き換えるような処理を行うファイルが存在すること自体、好ましくありません。
複製で使用されたファイルは削除するとともにプラグインそのものも、必要がなければ停止、もしくは削除しましょう。

※複製元である本サイトにも「wp-snapshots」が生成されていますので、作業完了後は削除することをお勧めします。

サイト複製の注意点

これまで紹介した手順はもちろんサーバ移転でも使えます。

  1. 検証のためのテスト環境作成
  2. 異なるサーバへの移設

ただし、ドメインが同一で移設を行う場合には新規サイトのセットアップを先に行わなければなりません。
このような際にはhostsファイルを使った仮想的に新サーバにアクセスすることができます。

もう悩まない!hostsファイルの書き方

なお、メジャーバージョンアップに備えて検証環境の構築というような趣旨であれば、公開環境の元サイトでは自動更新を停止しておきましょう。
WordPressのルート階層のwp-confing.phpの最下部に下記の1行を追加します。
これで自動更新機能がキャンセルされます。

define( 'AUTOMATIC_UPDATER_DISABLED', true );

本番ドメイン内に検証サイトを構築する上での注意点はひとつだけ。
検索エンジンにインデックスされないよう対処することです。
表示設定の検索エンジンでの表示で「検索エンジンがサイトをインデックスしないようにする」をチェックすることで検索エンジンにインデックスを拒否するnoindexタグが出力されます。
さらに強力に検証サイトをガードしたい方はWordPress全体の閲覧制限を実施することをお勧めします。

超~お手軽なWordPress全体の閲覧制限

profile image

執筆:R3098

WEBサービス構築・監修が生業です。WordPress 関連では Aurora Heatmap などのプラグイン開発も行っています。サイト運営者の力になりたいと考えます。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトは reCAPTCHA によって保護されており、Google のプライバシーポリシー および 利用規約 に適用されます。

reCaptcha の認証期間が終了しました。ページを再読み込みしてください。