WordPress のテスト環境を作るのは超簡単【Xサーバー】

さてさて、アップデート3部作もようやく終わろうとしている（笑

で、こちらの記事の最後に「余談」として書いているのだが、実は今回の記事が本丸だったりする（笑

「WordPress のテスト環境」に至る前日談

もともとは仲間うちで「WordPress のメジャーアップデートのときに毎回 Twitter のタイムラインとかが阿鼻叫喚になってるのを見るのがイヤだから、なんかアップデートするときに注意するポイントとか記事にしたらいいかなー」と相談したのが始まり。
最初は今回の WordPress 5.8 のアップデートの際に気をつけることを書く、くらいに考えていたのだが、話しているうちに

• いい感じのアップデートの仕方って？
• 正しい付き合い方を知ってほしい
• ダメだったときどうする？
• アップデート前にテストしようよ

みたいなキーワードがいくつか出てきたので、じゃあそれについて書こう、と思ったのが結果としてこの3部作となったわけだ。

いざ書いてみたらまだ足りないところとかもっと説明したいところとかはあるが、まずはこれを知ってもらうのがとにかく先決かな、ということでざーっと書いてみた。

いざ本丸へ

そして本丸だ（笑
これまでの記事が外堀埋めただけとか考えると気が遠くなる…

ちょっと前に WPZoomUP で『それ使ってみたい！みんなのローカル環境座談会』という話をさせてもらった。
その時話した内容については自分でもブログに書いたのだが、その時のメインの話はローカル環境（自分のパソコンの中で WordPress を動かせるようなアプリケーション（例えば Local とか）を使うこと）だったのだが、後半の座談会のなかで「最終的にはサーバーでのテスト（テストサーバーを用意するとか）が必要よね」っていう話が出て、みんなが納得したという経緯があった。

ほとんどの場合はローカル環境でテストできるし、特に開発をする場合はローカル環境は必須になるが、それでも最終的には公開するサーバーと同等の環境で表示確認をしたりクライアントさんの確認をとったり、ということが必要になる。
あくまでもローカル環境は『開発環境』であって、最終的な表示確認などはサーバー環境でないと同じ挙動になるかどうかは確実ではない。それもあって、「やっぱりサーバー上でのテスト環境のことも知っておいてもらわないと…」となったのだ。

「テスト環境」と「ステージング環境」

ここで「テスト環境」と「ステージング環境」の（言葉の）違いも説明しておきたい。
ちょっとググったらよい解説記事があったのでリンクを張っておく。

開発環境、テスト環境、ステージング環境、本番環境について｜gun｜note

この記事を書いた人はどうやらディレクターらしい。
この記事の中でも触れられているが、仕事にしているのでなければ、一般的には「テスト環境」と「ステージング環境」の違いは区別がつかないのではないだろうか。

ここの記事の中では

• テスト環境（検証環境）
  • 制作内容に問題が無いか検証する環境
• ステージング環境
  • 本番環境とほぼ同じ環境

と区別している。

例えば僕の場合、仕事ではまさにこの記事にあるように

• ローカル環境（開発環境）
• テスト環境（検証環境）
• ステージング環境
• 本番環境（公開環境）

の4つを利用していて、

1. まずローカル環境で開発し、
2. それをテスト環境でチェックして（もし共同開発している人がいたらここでその分とがっちゃんこしてチェック）
3. ステージング環境で問題ないことをクライアントさんにもチェックしてもらい
4. 本番環境に公開する

ような流れになる（もちろん公開までには1〜3は行ったり来たりする）。
主に僕（がいる会社）が行っている運用では、ステージング環境は公開直前の状態で、基本的にステージング環境と公開環境とは差分がない（ステージング環境には基本的に完成形のものだけを反映して、ステージング環境で確認されたものはそのまま公開する）ような形で行っていることが多い。
プロでないならばここまでする必要はないだろうが、可能ならば 1〜2〜4、せめて 2〜4 の流れは必要だ、というのが僕の意見だ。

つまり、今回主題にしたいと考えているのはまさにここで説明している『テスト環境』になる。
まさに「テスト環境 = 検証環境」なのだ。

そもそも今回のきっかけである「WordPress のメジャーアップデートのときに毎回〜」を避けるためには、いきなりアップデートする前にまずはテストできる環境でアップデートしてみて、そこで問題がないか確認してから公開環境でアップデートするのが本筋だといえる。
これを面倒と思うかどうかは個人に委ねられるが、この記事でも書いたように、

WordPress を利用する、ということは間違いなく「こういうことがずっと続く」ということと同義

なのだ。
このイベントのスライドのなかで冗談めかして言ったのだが、WordPress を利用している時

「サイト管理者」はあなた

だということを意識しなくてはならないだろう。

こんな話をすると「WordPress めんどくさい…」となるかもしれないが、WordPress で得られる自由を享受するためには必要なことだ、と考えていただくしかない。
「自分で管理する」ということは、「自分で管理『できる』」ことと同義なのだ。

WordPress のテスト環境を作るのは超簡単

ちょっと脅すようなことを書いたが、これを実現するのは実はまったく難しいことではない。
なぜなら、この記事を読んでくださっている読者の方は（きっと）ほとんどが日本の有名なレンタルサーバー会社を利用していると思うからだ。

皆さんは「WordPress 簡単インストール」を利用したことがあるだろうか？
一度でもこれを利用したことがあるなら WordPress のテスト環境を作るのはまったく難しくない。この「WordPress 簡単インストール」を使えばいいだけだ。

このブログ自体はXサーバーのレンタルサーバーを利用している。
なので、今回は実際にこのブログを題材に「テスト環境」を用意してみたいと思う。

「これまでテスト環境を持ってなかったのか？」と言われてしまうと困るのだが（笑）、僕のブログの表示が崩れていて困る人はいないし（笑）、なにか機能を追加しようと思ったときはローカル環境で開発したものをそのまま公開していたので、いわゆる「テスト環境」は利用していなかった。
もちろんアップデート前には、ローカル環境で事前にアップデートして表示確認したり機能の確認などはしていたのでご安心を（笑

サブドメインは自由に追加できる

無限に作れるわけではないだろうが、いま運用中のドメインとサーバースペースがあるなら、サブドメインは自由に追加可能だ。
「サブディレクトリー」にするか「サブドメイン」にするかはそれぞれの方針だとは思うが、ここでは「サブドメイン」として話を進めていく。

Xサーバーでのテスト環境作成手順

この記事を読んだXサーバーの中の人からツッコミが入ることを待ちつつ（笑）、手順を進めていこう。

【2021/07/25 追記】
別方面からツッコミがあったので補足（笑
その内容は「All-in-One WP Migration 使えばいいんじゃね？」というものだったのだが、僕もそう思います（笑）。ただし、ついこの間までは。

こんな記事やこんな記事やこんな記事に書いたとおり、僕自身めちゃくちゃ All-in-One WP Migration 推し（笑）だったので、もちろんこのプラグインが使えるならこれが最も楽ちん。必要なファイルやデータを全部ひとまとめにしてくれるし、なんと言っても Search Replace の部分もプラグインがやってくれるので難しいことはほんとにいらない。

ただ、この All-in-One WP Migration 、管理画面からのファイルアップロード容量の上限がサーバー設定に依存していて、サーバーによっては最大 2MB までとかになっていて、インポートしたいファイルがアップロードできなかったりする。

つい先日までは無料でアップロードの上限を 512MB まで上げられるアドオンを配布していたのだが、その配布が終了してしまい、有料のアドオンを購入しないと制限が変更できなくなってしまった、というのがその最大の理由。
なので All-in-One WP Migration を使わなくてもできる方法を、ということで wp-content 、.sql ファイル、Search-Replace-DB を利用する方法の解説を書いたというのが今回の記事の内容がこのような手順になった経緯になる。

だけどよく考えたらこれだけ何度もサーバーパネルにログインしてるんだったら php.ini の設定変更くらいできるよね…（笑
そこもスクリーンショットつけてちゃんと解説すればいいし。

あれ？なんとなくまたフラグが立った気がして嫌な予感しかしないんですけど…。

事前準備

まず一番最初に、事前に用意しておくべきものを列記する。

• 公開環境の WordPress の wp-content フォルダまるごと
• 公開環境の WordPress のデータベースをダンプした .sql ファイル

『 wp-contentフォルダまるごと』は FTP でダウンロードをすればよい。容量によって時間がかかることも考えられるが、これは必ず用意しよう。

wp-content フォルダのうち、最も容量が多いのは uploads フォルダだと思うので、これはいったん除外してあとから含めるとか、必要な画像だけピックアップしてほかは削除するなどしてもいいだろう。
テスト環境で大事なのはあくまでも「アップデートや機能（プラグインなど）追加の前後で表示が崩れたり変わったりしないか」を確認することなので、必ずしも公開環境が完全に復元できている必要はない。もちろん完全に同期できていれば比較もしやすいが、変更の前後で表示を比較するページや記事が決まっていれば、それらを変更の前後で確認すればいいだろう。

もうひとつ、.sql ファイルはサーバーパネルにログインし、phpMyAdmin から取得する必要がある。

公開サイトの「データベースをダンプ」する

「データベースをダンプする」とは、該当するサイトで利用しているデータベースのテーブルの中に保存された情報を .sql ファイルに出力することだ。
コマンドラインを利用して mysqldump したり、wp コマンドがインストールされていれば（WordCamp でスポンサーをするような日本のレンタルサーバー会社であれば wp コマンドは最初からインストールされていると思っていい） wp db export などでダンプできるが、今回はコマンドラインを利用しない一般的なユーザーを想定して phpMyAdmin を利用することにする。

Xサーバーの「サーバーパネル」にログインするとこのような画面になる。
ここで、画面中央付近にある「データベース」の「phpmyadmin(MySQL5.7)」を選択する。

この画面で入力する「ユーザー名」と「パスワード」は、『公開環境のデータを格納している』データベースに接続するための「ユーザー名」と「パスワード」になる。
これは基本的にご自身の手元に控えがあるはずだが、もしわからなくなった場合は wp-config.php ファイルに接続情報の記載があるので確かめよう。

phpMyAdmin にログインすると、そのデータベースサーバー内にあるデータベースの一覧が表示されるので、該当するデータベースを選択して開く。
ここを間違えてしまうと違うサイトの情報を取得してしまうので充分注意しよう。
「そのサイトで利用しているデータベース名」も wp-config.php ファイルに記載があるので参考に。

正しくデータベースを開くと、該当するサイトで利用しているテーブルの一覧が表示される。
この例ではプラグインが生成するテーブルも含まれているので数が多いが、最低でも

• wp_commentmeta
• wp_comments
• wp_links
• wp_options
• wp_postmeta
• wp_posts
• wp_terms
• wp_termmeta
• wp_term_relationships
• wp_term_taxonomy
• wp_usermeta
• wp_users

の12のテーブルは含まれているはずだ。
これらは WordPress をインストールしたら自動で作られるテーブルになる。
データベースをダンプするためには、この画面上部に並んでいるタブのうち「エクスポート」を選択する。

ここからはデータベースのバックアップ – WordPress Codex 日本語版に詳しく記載がある。
ここで「簡易バックアップ」と「詳細バックアップ」それぞれ解説があるが、僕はこれまで「詳細バックアップ」の方法でしかやったことがない…。

その後の項目でコマンドラインからのダンプも解説されているので、興味がある方は読んでみてほしい。

これで

• 公開環境の WordPress の wp-content フォルダまるごと
• 公開環境の WordPress のデータベースをダンプした .sql ファイル

が用意できたことになる。

ここまで来たら、もうひとつだけ事前に用意しておきたいものがある。

Search-Replace-DB

それが

• interconnectit/Search-Replace-DB: This script was made to aid the process of migrating PHP and MySQL based websites. Works with most common CMSes.

だ。

この Search-Replace-DB は、テスト環境にデータベースをインポートした後に、ドメインを置き換えるために利用するプログラムだ。

ここをちょっと解説すると、例えば公開環境のドメインが https://example.com 、テスト環境のドメインが https://test.example.com だったとすると、いまダンプした .sql ファイルの中にはすべて公開環境の https://example.com のデータが含まれているので、これをただ読み込ませただけではテスト環境の記事を見ようとしても公開環境のページが開いてしまう。
WordPress のエディターから入力したデータはすべてデータベースに格納されていて、それはサイトの URL も同様だ。
このデータベースの中のデータに含まれている URL を https://example.com から https://test.example.com へ正しく置換するのが Search-Replace-DB だ。
詳しくは説明しないが、.sql ファイル上でただ URL の文字列だけを置換しても、WordPress が使う正しい形式で置換できないのでやってはいけない。

Search-Replace-DB のリンクを開くと GitHub の画面になるので慣れていない人はギクッとしてしまうが、これもただファイルをダウンロードするだけならなんてことはない。

ここで画面中央付近にある緑色の「Code」ボタンをクリックするとプルダウンが開く・

プルダウンの一番下に「Download ZIP」のリンクがあるので、ここをクリックして .zip ファイルをダウンロードしておく。

ここまでが「事前準備」になる。

いよいよテスト環境の作成

ここまででも既にもうなかなか大変だったかもしれない（笑）が、本番はここから。
FTP を使ってファイルをダウンロードしたり、データベースをダンプしたりというのは慣れないとちょっと大変だが、実は普段からバックアップを取っていればいいだけなのだ。
バックアッププラグイン BackWPup – WordPress Backup Plugin や UpdraftPlus WordPress Backup Plugin を利用すれば、定期的にサイトのバックアップを取ることができる。
これらのプラグインでは、データベースだけでなくサイトのファイルのバックアップも取ることができるので、普段からこれらを使っていればわざわざこのために FTP や phpMyAdmin を使うこともない、というわけだ。

もちろん、バックアップファイルからテスト環境を作るのではなく、いま現在の最新の状態からテスト環境を用意したい場合は前述した手順で進めればいいし、上記のプラグインが入っているならプラグインの管理画面からデータベースをエクスポートできるだろう。

サブドメインの作成

サブドメインを登録するのはごく簡単だ。
まず、Xサーバーの「サーバーパネル」の画面右上付近にある「ドメイン」の「サブドメイン設定」を選択する。

最初に「ドメイン選択画面」が開くので、サブドメインを作成したい該当のドメインを選択する。

サブドメイン設定画面が開いたら、「設定対象ドメイン」がサブドメインを作成したいドメインになっているかを確認したうえで、上部の「サブドメイン設定追加」タブを選択する。

サブドメインの入力欄があるので任意の文字列を入力する。この画像では「stg」としている（「テスト環境」と「ステージング環境」は違う、と書いておきながらこれか…すいませんすいません）。
Xサーバーの場合、サブドメインのルート（サブドメインにブラウザでアクセスしたときに表示されるディレクトリ）は親のドメインの「public_html」の中に作成される。
その時のディレクトリの名前を指定できるので、どちらか（サブドメインすべてのドメイン名かサブドメイン名か）好きな方を選べばいい。

ここまでできたら確認画面へ進み、問題なければ追加して終わりだ。

サブドメインを作成してからその URL が閲覧できるようになるまで、最大で1時間くらいかかることもある。
このサブドメインの作成作業は事前に済ませておくとよいだろう。

WordPress の簡単インストール

これも同じくサーバーパネルから始める。ほとんどの方は既に経験済みの手順になるのではないだろうか？
まずはサーバーパネルの画面左下にある「WordPress 簡単インストール」を開く。

ここでも「ドメイン選択画面」が開くので、WordPress をインストールしたい該当のドメインを選択する。

「WordPress 簡単インストール」の画面が開いたら、先ほどのサブドメイン設定画面のときと同様に「設定対象ドメイン」がサブドメインを作成したいドメインかを確認した上で、上部の「WordPress インストール」タブを選択する。

「WordPress インストール」タブに移動したら、サイト URL のプルダウンをクリックして設定したサブドメイン（この場合は stg.lunalunadesign.net ）を選択する。

あとはサブドメインのサイトに設定したい項目を任意に入力していく。
ここは結局このあとデータベースを上書きするのですぐに消えてしまうところではあるが、とはいえあまり適当な（例えば簡単なパスワードとか）設定をするのはおすすめできない。
いったんエディターを開いてメモしておけばいいので、正しく設定しておこう。

入力して確認画面に進むと、設定した内容が一覧表示される。
ここで

• MySQL データベース名
• MySQL ユーザー名
• MySQL パスワード

はメモしておこう。これらの値はこのステージングサイトがある限り（データベースを利用する限り）は使い続けることになる。
これもいまメモしておかなくても、次の画面やあとから wp-config.php ファイルで確認できるが、改めて FTP で接続したりと二度手間になってしまうのでこのタイミングでメモしておくのがいいだろう。

「インストールする」ボタンをクリックすればそれで完了。
この完了画面でも MySQL パスワードなどを確認できる。

この完了画面で管理画面の URL がリンクになっているので、そのリンクをクリックしてテスト環境の WordPress にログインしてみる。

インストール時に入力したユーザー名とパスワードでログインできるはずだ。

トップページにアクセスすると、いつもの Twenty Twenty-one の画面が表示される。

これでいったんテスト環境が「動く」ところまでは確認できた。
いよいよこの次からは「テスト環境をテスト環境として使うための」の構築に進む。

公開環境の WordPress の「wp-content」フォルダをまるごとテスト環境にアップロード

まず最初に、ここで用意した公開環境の wp-content フォルダをまるごとテスト環境にアップロードする。FTP では「上書き保存」を選択しよう。

このwp-content フォルダの中に含まれる themes フォルダや plugins フォルダをそれぞれ別々にアップロードしてもいい。
ひとつずつ選択する手間を厭わなければ、こちらのほうがマシンにかかる負荷は少ないだろう。

もしかすると uploads フォルダのうち一部のファイルを除外しているかもしれないが、その場合は一部の画像がリンク切れになるがそこは我慢しよう。

ここの作業にはきっと時間がかかると思うので、ここでちょっと一息とりながら進めていこう。
残りはあと少しだ。

ここでの注意

wp-content フォルダのアップロードの途中、あるいはアップロードが完了していても公開環境にテーマ Twenty Twenty-one が含まれていない場合に先ほどのテスト環境にアクセスしてしまうと、エラー画面が表示されてしまう。

この作業を始めたら、テストサイトの管理画面とテストサイトのページを開いたブラウザは閉じてしまうか、触らないようにしておこう。

公開環境のデータベースをインポート

次に公開環境のデータベースをインポートするのだが、データベースのインポートはエクスポートと比べるとめちゃ簡単なので省略（笑
先ほどと同じようにまずサーバーパネルにアクセスして phpMyAdmin を開き、今度はテスト環境で利用するデータベースにログインする。
このときに入力するデータベースのユーザー名とパスワードは、新しくテスト環境を作ったときのユーザーとパスワードなので間違えないように！！データベースが開いたら、データベース名が間違いなくテスト環境のものであることも確認しよう。
そこまで確認できたら、あとは先ほどダンプした公開環境の .sql ファイルをインポートすればよい。

エクスポートの場合は少々設定が必要だった（「簡単バックアップ」なら設定不要だが…）が、インポートはポチポチするだけ。

これでデータベースのインポートも完了する。

ここでの注意

この状態においても、先ほどと同様にテストサイトの画面を新たに開いたりリロードしたりしないようにしておこう。
ここで先ほどのテスト環境にアクセスしてしまうと、今度は公開環境にリダイレクトされてしまう。これはよく考えれば当然のことで、いまインポートしたのが『公開環境のデータベース』だから、データベースに記録されている URL は全部「公開環境の URL」なのだ。
ここでは（多分）エラーにならずにただ単に公開環境にリダイレクトされるだけだが、余計なことはしないに限る。ここでも触らずにいよう。

Search-Replace でドメインの置換

いよいよテスト環境構築作業も佳境だ。
ここが最もキモになるところで、テスト環境構築の一番のヤマ場だ。とはいえこれも慣れてしまえばなんということはない。
この「ドメイン置換」の方法を知っておくといろいろな場面で使えるはずなので、ぜひともチャレンジしてほしい。

では解説していこう。

Search-Replace-DB をアップロードする

Search-Replace-DB についてはこちらで解説したので詳細は割愛。
ここでは既に Search-Replace-DB をローカル（自分のパソコン）にダウンロード済みで、.zip ファイルも解凍してある前提で話を進める。

.zip ファイルを解凍すると、 Search-Replace-DB-master という名前のフォルダーができているはずだ。これは自分でわかりやすい名前にリネームしても構わない。
まずはこのフォルダーを FTP でステージング環境のドキュメントルート（今回の僕の例で言えば lunalunadesign.net/public_html/stg ）にアップロードする。

Search-Replace-DB にアクセスする

フォルダーがアップロードできたらその URL にアクセスしてみよう。
今回の僕のケースなら

http://stg.lunalunadesign.net/Search-Replace-DB-master/

になる。 URL の部分は適宜ご自分の環境に合わせていただきたい。
この URL にアクセスして以下のような画面が表示されたらまず第1段階は完了。

いよいよ Search-Replace-DB でドメインの置換をする！

Search-Replace-DB にアクセスできたら、それぞれの項目に入力していこう。
併せて画像も参照いただきたいが、

• replace 以下には置換元（公開サイト）の URL
• with 以下には置換先（テストサイト）の URL
• database_name にはデータベース名
• username にはデータベースのユーザー名
• pass にはデータベースのパスワード
• host にはデータベースのホスト名

をそれぞれ入力する。

ここはそれぞれ手打ちで入力すると入力間違いが発生するので、できるだけコピペで済ませよう。

もう一点、 replace と with に入力する URL は絶対に最後に / をつけないように要注意。
ここの URL の最後に / がついてしまっていると、URL が正しく置換されない。

ここまで入力したら、database_name 入力欄の下にある「Test connection」ボタンをクリックして見よう。

次の画像のように 「Success. You are connected.」と表示されたら OK。もしなにかエラーになったら再度ユーザー名、パスワードなど入力項目に間違いがないか確認しよう。

Dry Run してみる

いよいよ置換、となるその前に、一度テストしてみよう。
これは実際の仕事現場でデータベースのドメイン置換をする際にも必ずやっている（仕事の場合は100% wp-cli の wp コマンドでやるけれど）。ここでミスをすると後々面倒なので、必ずテストしよう。

Search-Replace-DB の画面で「Let’s go」と書かれたエリアがある。
そこの上部のボタン「Do a safe test run」をクリックしよう。

これは実際にデータベースのドメインの置換はしないけれど、置換をするのとまったく同じ動作でテストするものだ。

「Do a safe test run」ボタンをクリックするとこんな画面になるはずだ。

これをちょっと下の方にスクロールしてみると、データベースのテーブルでどれだけの項目が置換されるのか、数で確認できる（ Cells changed の列に注目）。

仮にここが全部「0」だったりしたら、最初に入力した

• replace 以下には置換元（公開サイト）の URL

が間違っている（つまり「該当する URL がデータベースの中に見つからない」）ということになるので、正しい URL を入力し直そう。

いざ、置換！

ここまで確認できたら、あとは実際にドメインを置換する。
先ほどクリックした「Do a safe test run」ボタンのすぐ下にある「Search and Replace」ボタンをクリックすればいい。

「Search and Replace」ボタンをクリックすると「ホントに置換しちゃって大丈夫？」と聞かれる。

間違いなければ「OK」をクリックする。
これでデータベース内の古い（公開環境の）ドメインが新しい（テスト環境の）ドメインにすべて置換される。

Search-Replace-DB を削除する

これで Search-Replace-DB の利用はすべて完了した。
「ドメイン置換」の最後の作業として、この Search-Replace-DB を削除する。

仮にこれが残ったままだった場合、データベースに簡単に接続できてしまう。例えばフォルダー名をなにか乱数のようなわかりにくいフォルダー名に変更していたとしても、Search-Replace-DB がサーバーの「公開領域」にあることに変わりはない。
このままでは重大なセキュリティリスクになってしまうので、ドメインの置換が完了したら Search-Replace-DB は絶対に削除しておかなくてはいけない。

削除する場合は FTP も不要で、置換されたテーブル一覧の下に表示されている「delete me」ボタンをクリックするだけだ。

「delete me」ボタンをクリックすると先ほどと同じように「ホントに消しちゃって大丈夫？」と聞かれるので、「OK」をクリックする。

最後に「Search/Replace has been successfully removed from your server」と表示されれば完了だ。

テスト環境を表示してみよう

ドメインの置換も完了したので、これで晴れてテスト環境が用意できた（はず）。
「できたはず」では不安なので、早速テスト環境にアクセスしてみよう。

まずは管理画面から

データベースをまるごと置換しているので、管理画面へのログインはテストサイトのインストール時に設定したログイン ID とパスワードではなく、「公開サイト」のログイン ID とパスワードに書き変わっていることに注意。

ログイン後のダッシュボードの表示が「公開サイトと同等」になっているか確認しよう。
ぱっと見で変更がわからなかったとしても、例えば投稿一覧画面を開いてみれば、自分が書いた記事がすべてインポートされているのがわかるだろう。

トップページ以下、各ページにもアクセスしよう

トップページにアクセスして公開環境とまったく同じ見た目になっていればまずは OK。
（もしかしたら一部アップロードしていない画像が表示されていない、などはあるかも）
トップページを確認したらほかの固定ページ、アーカイブページ、記事ページなどもそれぞれ表示してみよう。

ここまででちゃんとできていたらまずはテスト環境の完成です！！

やったー、おめでとうございます！！

完成だー！と両手離しするその前に

見た目としてのテスト環境はこれで完成なのだが、『運用するテスト環境』としてはあとひとつ作業がある。
もう残りあと少し、頑張りましょう！

Basic認証をかける

今回作ったテスト環境は、公開環境からデータベースをまるごと持ってきているので、いまこの時点では公開環境の「完全なクローン」になっていると思われる。
となると、このテスト環境が検索にインデックスされてしまうと非常にマズいことになる。
もちろん、検索エンジン対策だけでなく、テスト環境が一般に公開されて誰でもアクセスできてしまっては困る。

なので、このテスト環境に Basic 認証をかけておこう。

Xサーバーは Basic 認証をかけるのもとても手軽だ。
またサーバーパネルから、その左中央部にある「アクセス制限」をクリックする。

アクセス制限設定の画面が開いたら「設定対象ドメイン」を選択し、一覧を表示させる。

ここで Basic 認証をかけたいのは /stg フォルダ以下なので、 /stg の欄の右側、「ユーザー設定」リンクを開く。
するとユーザー ID とパスワードを入力する欄が表示されるので、任意のユーザー ID とパスワードを設定しよう。

このユーザー ID とパスワードはサイトを閲覧する際に必要になるので、これもメモしておこう。
ユーザー ID とパスワードを入力したら確認画面へ進もう。

確認画面が表示されたら「追加する」ボタンをクリックして一覧へ戻ろう。

「アクセス制限」のラジオボタンを「ON」に切り替えて「設定する」ボタンをクリックすると Basic 認証が設定される。

ちゃんと Basic 認証が有効になったか確認する

Basic 認証を設定したら再度テストサイトにアクセスしてみよう。
正しく「ログインの認証ダイアログ」が表示されたら Basic 認証も有効になっていることがわかる。

ユーザーのパスワードを変更しておく

公開環境とテスト環境でパスワードが違うと管理が煩雑になってしまう、という意見もあるが、僕はそのままパスワードを使いまわしているセキュリティリスクのほうが高いと思うので、これは変えておこう。
これは自分だけでなく、複数のユーザーがいる場合はすべてのユーザーで変更しておこう。それぞれのユーザー ID でのダッシュボードのログイン画面で「パスワードをお忘れですか ?」リンクをクリックしてメールを飛ばすのがいいと思う。

あとになって「あの時パスワードを変えていれば…」とかなるのはイヤだ…

ダッシュボードの配色を変更しておく

実際に作業をしていると、公開環境で作業しているのに「いま公開環境にいるのかテスト環境にいるのか」がごちゃまぜになることがある。もちろんブラウザでURLを確認すればいいのだが、集中しているとうっかりすることもあるし、例えばライターさんやWeb担さんならなおさらかもしれない。
そんなときにこれをやっておくと公開環境とテスト環境を間違える可能性がぐっと減るし、設定は超簡単なのでオススメ。

WordPress のダッシュボードから「ユーザー＞プロフィール」の画面を開こう。ダッシュボード右上の自分のアイコンから「プロフィール編集」を選んでもいい。

開いてすぐ見える「個人設定」に『管理画面の配色』というメニューがあるので、ここで好きな配色を選ぼう。
ここは何度でも切り替えできるし、配色を選ぶとすぐに背景色が変わるので、変更したあとのイメージも把握できる。

これは「個人設定」というところから分かるとおりそのユーザーだけでの設定になる。
好みによって公開環境の配色を変えてもいいかもしれない。

手軽にミスを防ぐいい方法だと思うので、ぜひお試しあれ。

テスト環境の完成

「WordPress のテスト環境を作るのは超簡単」と書いたんですが、簡単だったでしょうか…（笑

また例によって（笑）長々とした記事になってしまったが、手順をひとつずつ追っていったので長くなったということでご容赦願いたい。
確かに記事としては長いのだが、項目ひとつずつは難しいものではない。あえて言うならば「Search Replace」がちょっと難しいだろうか。

この記事をなぞっていけば（時間は少々かかるかもだが）間違えずにできるはずだし、ここで作ったテスト環境があれば、当初の目的であった「アップデート（や機能開発）を事前に確認できる」環境が手に入れられるのは間違いない。

こちらの「ローカル環境」を作る記事と併せてご検討いただければ幸いだ。

テスト環境の運用で注意すべきポイント

さて、テスト環境ができたところまではいいとして、最後に『作ったテスト環境の運用上での注意事項』について触れておこう。
先ほど最後に設定した Basic 認証のように、テスト環境を運用するにあたっていくつか注意しておくべき点がある。

「wp-config.php」ファイルへの記述

僕が普段テスト環境を作る際に、いつも記載しているものをご紹介しておこう。
wp-config.php ファイルには、サイト全体のオプション設定を記載することができる。

ひとつはこちらの記事にも記載のある「デバッグ機能の有効化」だ。

define( 'WP_DEBUG', true );

これはテスト環境ならば有効化しておくことを積極的におすすめしたい。
通常は表示されない細かなエラーが表示されるようになるので最初は面食らうかもしれないが（笑）、これらのエラーを解消していくことで大きなエラーを未然に防いだりできる。
エラー文は基本的に英語なのだが、何度も見ているとだいたい似たような文章が表示されていることに気がつくし、解消方法もエラー文でググればだいたいは出てくるはずだ。

もうひとつはプラグイン「jetpack」に関連する記述だ。

define( 'JETPACK_DEV_DEBUG', true );
define( 'JETPACK_STAGING_MODE', true );

これは公開環境でプラグイン「jetpack」をインストールして、かつ有効化している場合に必要な記述になるのだが、テスト環境に公開環境のデータベースをインポートした際に jetpack の設定もすべてインポートされるが、この記述がなかった場合、誤って公開環境とテスト環境が入れ替わって認識されてしまうことがある。
いったん間違って認識されてしまうと直すのにはなかなか手間がかかってしまうので、最初から wp-config.php ファイルにはこの記述をしておくとよいだろう。
jetpack が入っていない、あるいは入っているけれど有効化されていな場合はこの記述があってもなにも起きない。なので僕はミスを防ぐためにいつもこれも書いている（笑

プラグインやウェブサービスのライセンス

ここで説明したプラグイン「jetpack」の例でもあったように、外部サービスと連携している機能を利用している場合は注意が必要だ。
利用しているサービスが「1サイトごとにライセンス契約が必要」だったり、改めて認証が必要だったりすることもあるだろう。

これらは個々のサービスごとで確認するしか方法はないが、こういったサービスとの連携ができていないとテスト環境下で機能の検証ができないのだとすると、テスト環境を用意した意味が半減してしまう。
いざテスト環境を作ったあとで「実は別途有料契約をしなくてはならなかった」と判明しても困ってしまうので、サイト内でこういった『外部のサービスと連携する機能を利用している』場合は、事前にそのライセンスや契約条件について確認しておこう。

放置しない

そして最後に、「放置しない」ということが挙げられる。

「そんなことするわけない」と思うだろうが、公開環境と違ってテスト環境は開発の時以外は触らないのでうっかり放置してしまうこともないとはいえない。
また、テスト環境はあくまでもテスト環境なので、ある程度開発が進んで機能が充分用意できたら「開発を終了するのでテスト環境も使わなくなる」こともあるだろう。

公開環境であればアップデートに頻繁に追従していても、（特に開発が終了した）開発環境などは放置してしまったりしていないだろうか？
いくら Basic 認証をかけて複雑なパスワードを使っていたとしても、WordPress 本体やプラグイン、テーマが古いまま放置されていてはセキュリティリスクはどんどん高まってしまう。

なので、いくら「テスト環境だから」といってもそれを放置せず、きちんとアップデートに追従し、開発が終わったのならテスト環境そのものも削除する必要があるだろう。
必要なバックアップデータさえあれば、いったん削除したあとでもいつでも復元は可能だ。
問題は『放置された状態が公開されたままになっている（外部からアクセス可能になっている）』ことなので、「自分が管理者である」ということを充分意識しておこう。

終わりに

いざ記事を書き始めてみたら、これが本丸（笑）だっただけあって、この記事を書くのに一番時間がかかった…。

この記事をなぞりながら作業を進めていただければ、少なくともXサーバーでならどなたでもテスト環境を手軽に用意できるのではないだろうか。

公開環境だけでなく、もうひとつ似たような環境があってそのどちらも管理しなくてはならないとなると、たしかに手間は増えてしまう。
ただ、まさに今日リリースされた WordPress 5.8 に限らず、この3部作のなかで繰り返し出てきた WordPress のアップデートがリリースされた直後から目にする「アップデートしたら真っ白に…」みたいな話が少しでも減ってくれることを願うばかりだ。

アップデート3部作、さすがにこれだけのボリュームの記事を固め打ちすると疲れました…（笑

補足

「せっかくテスト環境を用意して事前にアップデートをテストしようと思ってたのに、アップデートがリリースされたら自動でアップデートされちゃった！！」という方はオレインさんのこちらの記事をご覧あれ。