Joeワードプレスでテーマ開発をしていると、本番データと同期した開発環境や、テスト環境がだいたい欲しくなります。「そうだ、ステージング環境を作ろう!」そんな時がステージング(staging)環境の出番です。後回しにしてしまいがちですが、重い腰をあげて、ステージング環境を作ってみます。今回、最も本番環境に近いテスト環境」として、本番のデータベースを直接参照しながら、新しく変更を加えたテーマのソースコードをさくっとテストできる環境を用意します。そもそも、「ステージング環境って?」という方はまず「開発・検証・ステージング。それぞれの環境の違いと役割」をご覧下さい。設置する環境の概念図ワードプレス開発において、多くの場合はワードプレスの「テーマ」を開発していると思います。いまから作るのは「テーマ開発」におけるステージング環境です。具体的には、以下のような環境です。Thmemに関するコードセット(=wp-content/themes/<あなたのテーマ>のディレクトリ配下)だけがテストできればいいわけですね。今回、このテスト環境を「本番と同じサーバーに」作ってしまいます。大前提としては、「開発したテーマを、本番データを直接使ってテストする」ですね。本番に反映する本当に直前の確認です。いくつかの注意点があります。注意1:開発が終わった更新のみ反映させるただし、いけてないテーマのコードを上記のステージング環境にアップすると、サーバー自体がダウンしたり、本番データを壊してしまったりするので、適していません。できるだけ深刻なバグがない状態で、テストを開始しましょう。注意2:データベースへの影響を考慮するまた、今回のような環境設定では、データに依存する機能をテストしにくい場合があります。開発している新しい機能に必要なデータが、本番の振る舞いに影響を与えてしまうようなケースがあり得るからです。実際の更新内容のリリース時には、そのような自体を迂回するために、開発中にわざとデータの後方互換を保つようにデータ構造の変更を設計する事もできます。先に新機能用のデータを本番に作成し(でも、本番の振る舞いに一切影響を与えない)その後、新しいテーマの機能をテストできるという見込みで、データ、その後、テーマコード、という2段階で本番に更新を行う事もできます(話が細かくなるので、今回はこれ以上は割愛します・・)注意3:データベースを分けたほうが良い時は、素直に分ける。今回の方法では、参照するデータベース名を指定するファイルwp-config.phpを独立で持つことができますので、データを分けたほうが良い場合は、wp-config.phpを書き換えて、完全にDBを別に持ってしまったほうがよいでしょう。データベースのデータ(SQL)はSQLインポートすることで、比較的容易に同期できるはずです(後述)。そもそも「ステージング環境」ではなく、大きくデータに依存するような機能を開発する場合は、本番環境とは別のサーバーにテスト用の環境を作り、」などのアプローチのほうが適切だと思います。→別記事「WordPressデータベースを本番環境と同期する方法まとめ」(執筆中)をお読みください。え、そもそも「ステージング」って何なの?って人はどうかこちらをお読みください:開発・検証・ステージング。それぞれの環境の違いと役割ではさっそく、ステージング環境を作っておいて、簡単にテストできるようにしましょう。WordPressステージング環境の作り方サマリーまずはサマリーから。(1)本番サーバーで、本番のWordPressとは別のディレクトリに、もう一つWordPressをインストールする。(これをステージング環境にします)(2)適当にサブドメイン(完全に別ドメインでもOK)を登録して、そのドメインが、1でWordpressを配置したディレクトリを指すように設定。(バーチャルホスト設定)(3)wp-config.phpを書きかえて、本番と同じDBを参照するにする。(本番のwp-config.phpを複製でもOK)。siteurlの値)を参照しないよう設定を書き込む。Slash)はいらないそうです。