ステージング環境
弊社では、各WordPressサイトに対して、本番サイトとは完全に分離されたWordPressステージング環境を無料で作成することができます。WordPressのバージョン、プラグイン、コード、その他一般的な開発作業をテストするのに有用で、数分で開発環境を作成し、他の人と共有可能です。
ステージング環境のさらなる追加、本番環境に近いステージング環境の利用、またはリソース集約型のサイトにおけるテストや開発をお求めであれば、プレミアムステージング環境アドオンをご利用ください。
標準およびプレミアムステージング環境の比較
プレミアムステージング環境は最大5つまで作成可能で、無料で使用できる標準ステージング環境よりも多くのリソースと機能が搭載されています。標準およびプレミアムステージング環境の違いは以下のとおりです。
| プレミアムステージング | 標準ステージング | |
| ワーカープロセス | 本番環境と同数 | 1 |
| CPU | 12 | 1 |
| RAM | 8GB | 8GB |
| CDN | ◯ | ✕ |
| エッジキャッシュ | ◯ | ✕ |
プレミアムステージング環境アドオンの詳細はこちらをご覧ください。
WordPress標準またはプレミアムステージング環境を作成する
WordPressステージング環境の作成は簡単です。MyKinstaにログイン後、左サイドバーから「WordPressサイト」を開くと、WordPressサイト一覧が表示されます。ステージング環境を作成したいサイトを一覧から選択するか、画面上部の「ジャンプまたは検索…」バーで検索して、「新規環境の作成」をクリックします。
表示される「新規環境の作成」ポップアップで「プレミアム環境」または「標準環境」を選択して、「続行」をクリックします。
作成する環境の種類を選択するプロンプトが表示されます。ステージング環境を作成する方法は以下の3つから選択できます。
- 既存の環境を複製：既存の環境（本番またはプレミアムステージング環境）を新しい標準ステージング環境に複製することができます。
- 新たにWordPressをインストール：空の（コンテンツのない状態の）WordPressをインストールし、WordPressサイトがすぐに使用できるようになります。
- 空の環境（WordPress無し）：WordPressサイトの実行に必要なすべてのソフトウェア（ウェブサーバー、PHP、MySQLなど）をインストールしますが、WordPressコアはインストールされません。Duplicatorを使って弊社にサイトを移行したり、特別なファイル構造でBedrock/Trellisを利用したりするのに便利です。
方法1. 既存の環境を複製
「既存の環境を複製」を選択すると、任意の既存環境（本番環境またはプレミアムステージング環境）を新しい標準ステージング環境として複製することができます。
- 環境名：3文字以上12文字以内で任意の名前を設定します。
- 複製対象の環境：ステージング環境に複製する既存の環境を選択します。
方法2. 新たにWordPressをインストール
「新たにWordPressをインストール」を選択すると、サイトの細かな設定を行うことができます。各フィールドの役割は以下の通りです。
- 環境名：3文字以上12文字以内で任意の名前を設定します。
- WordPressサイトタイトル：WordPressサイトの表示名を設定します。使用しているテーマによっては、ブラウザのタブなどで訪問者に表示されることがあります。サイトタイトルは後ほどWordPress管理画面で変更可能です。
- WordPressサイト管理者のユーザー名：WordPressの管理者ユーザー名を設定します。環境作成後、必要に応じて複数のWordPressユーザーを追加可能です。最大限のセキュリティを確保するため、ユーザー名には「admin」以外を使用することが推奨されます。
- WordPressサイト管理者のパスワード：WordPressの管理者パスワードを設定します。セキュリティ上の理由から、強力なパスワードが自動的に適用されます。パスワードを変更するには、「新しいパスワードを生成」（再読み込みアイコン）をクリックしてください。WordPressで後からパスワードを変更する方法はこちらをご覧ください。
- WordPressサイト管理者のメールアドレス：WordPressから重要な通知を受け取るための管理者用メールアドレスを設定します。
- WordPressサイトをマルチサイト化する：WordPressマルチサイトを作成する場合は、このボックスにチェックを入れてください。「サブドメイン」または「サブディレクトリ」のいずれかを選択することができます。
- WooCommerceをインストールする：人気の高いECプラグインWooCommerceを使ってECサイトを作成することができます。このボックスにチェックを入れると、自動でインストールされます。
- Yoast SEOをインストールする：Yoast SEOは、WordPressの数あるSEOプラグインの中でも人気の選択肢です。300万以上のインストール、高評価（5/5）を誇ります。このボックスにチェックを入れると、自動でインストールされます。
- Easy Digital Downloadsをインストールする：デジタル製品に特化したECサイトの構築に便利なEasy Digital Downloadsをインストールすることができます。このボックスにチェックを入れると、自動でインストールされます。
方法3. 空の環境（WordPress無し）
「空の環境（WordPress無し）」は、Duplicatorを利用したサイト移行やBedrock/Trellisを用いたサイト構築に便利な選択肢です。
- 環境名：3文字以上12文字以内で任意の名前を設定します。
ステージング環境の作成
上記いずれかの方法で設定を終えたら、「続行」をクリックします。プレミアムステージング環境を作成する場合は、月額料金とお支払い方法の詳細が表示されます。同意の上、「プレミアム環境の作成」をクリックしてください。
ステージング環境にアクセスする
ステージング環境が生成されるまでお待ちください。表示されるまでに数分かかる可能性があります。環境が完成したら、画面上部にある「ジャンプまたは検索…」バーをクリックして、環境を選択します。
または、「WordPressサイト」画面のサイト一覧から選択することも可能です。
各環境の名前の横には丸印が表示されます。環境ごとに色分けされており、本番環境（Live）は緑、標準ステージング環境（Standard Staging）は黒、プレミアムステージング環境（Premium Staging）はオレンジです。また、ステージング環境用の接続情報、DNS、バックアップ、ツール、プラグインといった情報も表示されます。
ステージングサイトにアクセスするには、ステージング環境の「ドメイン」タブで、「URLを開く」をクリックします。また、「WordPressの管理画面を開く」をクリックすると、ステージングサイトのWordPress管理画面が開きます。
URL構造とドメイン
標準ステージング環境のデフォルトのURL構造は、以下のようになっています。
- 標準環境：https://stg-sitename-environmentname.kinsta.cloud
- プレミアム環境：https://env-sitename-environmentname.kinsta.cloud
古いステージングサイトをお持ちの場合、URLは以下のようになることがあります。
- https://staging-sitename-environmentname.kinsta.cloud
- https://staging-sitename.kinsta.cloud
- https://staging-sitename.kinsta.com
また、ステージングサイトに独自ドメインを追加することも可能です。
注意事項
本番サイトでSSLを有効にし、ステージング環境にそのサイトを複製すると、ステージング環境でもSSLが有効になります。
MyKinstaからphpMyAdminを起動できます。「情報」タブで「phpMyAdminを開く」をクリックします。phpMyAdminのステージング環境用URLは、以下のようになります。
https://mysqleditor-stg-sitename-environmentname.kinsta.cloud
ステージング環境更新する
ステージング環境の作成後に本番サイトに変更を加え、その変更をステージング環境に反映したい場合は、選択的プッシュ機能を使用することができます。これにより、ステージング環境をわざわざ削除して再作成する必要がなくなり、作業が効率化され、ステージング環境のバックアップも保持できます。
本番またはステージング環境に別の環境の変更を反映する
WordPressステージング環境で行った変更を本番サイトに適用したい場合、本番環境にその変更を反映（プッシュ）することができます。
また、他のステージング環境に反映することも可能です。これは、本番環境に加えた変更をステージング環境に反映させ、ステージング環境を更新するのに便利です。
選択プッシュ機能では、反映する内容を以下のように細かく制御可能です。
- ファイルのみ
- データベースのみ
- 特定のファイルとフォルダ
- 特定のデータベーステーブル
- ファイルおよびデータベース
環境の反映は数回のクリックで実行可能です。反映を行う際には、以下の確認事項を必ずご一読ください。
注意事項
- 選択的プッシュ機能は、トラフィックの少ない時間帯に使用したり、万が一に備えて開発者を雇用したりしておくなど、慎重に使用することをお勧めします。開発者の採用についてはこちらをご覧ください。
- 必要に応じてロールバックできるよう、バックアップが自動的に作成されます。※本番サイトがECサイトのような動的な（急速に変化する）サイトの場合、反映してからバックアップが復元されるまでの間にデータが失われる可能性があります。
- 環境設定（リダイレクト、ジオロケーション、PHPやNginxの設定など）は、ファイルまたはデータベースのみを選択した場合でも、反映対象に含まれて（ファイルまたはデータベースのみを選択した場合も）、本番サイトの環境設定が完全に上書きされます。
- 本番環境への反映が完了したら、テーマやプラグインに組み込まれているキャッシュ、ブラウザのキャッシュをクリアし、サイトをテストして動作を確認してください。
- データベースの変更を反映する際に、「検索と置換を実行」を選択すると、ステージング環境のドメインが自動的に本番サイトのドメインに置き換えられます。
- 「すべてのファイルとフォルダ」を選択すると、プラグイン、テーマ、wp-content/uploads内のファイルなど、すべてのファイルが反映されます。
- テーマやプラグインのコードにおける、ハードコーディングにより記述されたURLは、別途本番サイトのURLに変更していく必要があります。
- ステージング環境でパスワード保護（.htpasswd）が有効になっている場合であっても、本番環境には引き継がれません。本番環境でこの設定が必要とされる場合には、本番環境にて、あらためて有効化する必要があります。
- WooCommerceを使用している場合、ステージング環境での変更を本番環境に反映する際、新規顧客からの注文と既存顧客からの注文は区別されません。本番サイトへの反映を開始すると、ステージングサイトをそのまま本番サイトにコピーし、ファイルとデータベースが上書きされます。これを回避するには、以下のいずれかの方法をとってください。
- データベースが上書きされないよう、選択的プッシュ機能でステージング環境のファイルのみを本番環境に反映する
- データベーステーブルのみを反映し、必要なWooCommerceテーブルを除外する
- 変更を反映する前に本番環境のデータベースファイルをステージング環境に反映して最新のデータをにプッシュし、データを最新の状態にする
WooCommerceの各データベーステーブルに何が含まれているかについては、WooCommerce Database Descriptionをご覧ください。また、ウェブ開発者と協力して作業を行ってください。WordPress開発者を採用する方法はこちらでご紹介しています。
- ステージングサイトを再確認し、エラーがあれば解決してから本番環境に反映するようにしてください。
- ステージング環境は、あくまで開発およびテスト用にご利用ください。本番サイト用には設計されておらず、正常に機能しない可能性があります。ステージング環境を本番サイトに使用する場合、弊社は一切の責任を負いかねますのであらかじめご了承ください。
- 本番環境への反映がステージング環境に影響を与えることはありません。本番サイトとは完全に分離されたままになります。本番環境への反映後は、再び変更を反映するまで、本番サイトに影響を与えることなくステージング環境で開発とテストを継続することができます。
- 弊社のCDNを本番サイトで利用中、ステージング環境から本番サイトに変更を反映しても干渉は起きませんが、反映後にCDNキャッシュをクリアすることをお勧めします（「サイト」＞（サイト名）＞「CDN」＞「CDNキャッシュをクリアする」）。
- マルチサイトを運営されている場合は、ステージング環境から本番環境への反映は慎重に行なってください。マルチサイトのセットアップ方法によっては、データベースの反映がうまくいかない場合もあります。選択的プッシュを使用して、すべてのデータベーステーブル、またはすべてのデータベーステーブル、ファイル、フォルダを反映する場合、データベースのコンテンツ全体が本番サイトに反映され、マルチサイト内のすべてのサイト（メインサイトとサブサイト）に影響します。
- BedrockやTrellisのような非標準のWordPressセットアップを使用している場合、
DB_PASSWORD変数を特定できないため、作成する環境でデータベースパスワードを更新できないことがあります。この場合は、環境の作成時にDB_PASSWORD変数を定義したファイルをMyKinstaで設定した新たなデータベースパスワードに手動で更新する必要があります。
選択的プッシュ機能で環境を反映する
以下の手順に従って、別の環境に任意のデータを反映することができます。
1. 環境の選択
MyKinstaにログイン後「WordPressサイト」画面を開き、反映先となる環境を選択します。プレミアムステージング環境を追加している場合は、複数のステージング環境から選択可能です。
2. 環境に反映
サイトを選択後、「別の環境に反映する」をクリックし、反映先となる環境を選びます。
3. 反映するファイルとデータベーステーブルを選択
表示されるポップアップで、以下のいずれかを選択します。
- ファイル＞すべてのファイルとフォルダ：すべてのファイルとフォルダを選択した環境に反映します
- ファイル＞特定のファイルまたはフォルダ：選択した環境に反映したい特定のファイルやフォルダを個別に選択します。この項目を選択すると出現するテキストエリアに反映する特定のパス/フォルダ/ファイルを定義可能です。WordPressの各ファイルの使用方法についてはこちらをご覧ください。
- データベース＞すべてのデータベーステーブル：すべてのデータベーステーブルを選択した環境に反映します
- データベース＞特定のデータベーステーブル：選択した環境に反映したいデータベーステーブルを個別に選択します。WordPressデータベースの詳細についてはこちらをご覧ください。
確認のため最後にサイト名を入力し、「（環境名）に反映する」をクリックします。
なお、以下の点のご注意ください。
- 反映が完了するまでにかかる時間は、ウェブサイトのサイズによって異なります。
- 反映が完了すると、MyKinsta内で通知が表示されます。
- ステージング環境から本番環境に反映する際は、プロセスの最終段階で数秒ほどサイトが停止します。
- ファイルまたはデータベースのみを選択した場合でも、環境設定（リダイレクト、ジオロケーション、PHPとNginxの設定など）は反映内容に含まれ、環境の設定を上書きします。
使用例とワークフロー例
以下、ファイルのみ、データベースのみ、またはその両方を反映したい場合の例をご紹介します。
すべてのファイルとフォルダのみを反映
- HTML、CSS、PHP を含むテーマファイル（データベースにデータが保存されていないもの）に直接変更を加えた場合
- WordPressのメディアライブラリに必要のないファイルをアップロードした場合
- サイトに独自のプラグインを導入しており、データベースに影響を与えない（データベースのデータを保存したり修正したりしない）変更をファイルに加えた場合
特定のファイルまたはフォルダを反映
- 1つのテーマに変更を加える場合、
themesフォルダ内のそのテーマの特定のフォルダを反映する - ステージングでプラグインの新バージョンをテストする場合、
pluginsフォルダ内にプラグイン専用のフォルダを反映する - テキストエリアに反映するパス/フォルダ/ファイルを定義し、特定の設定や構成ファイルの変更を本番環境に反映する
データベースのみを反映
※ステージング環境の作成後に本番環境のデータベースに加えた変更（コメント、新規コンテンツ、ECサイトでの注文、会員制サイトでの新規登録、フォーラムへの投稿など）は失われます。
- メディアのアップロード（画像、動画、その他のファイル）を含まない、投稿または固定ページの作成や編集
- ビルダー系プラグインを使って実施した投稿や固定ページのレイアウトの変更
- サイトのタイトルやキャッチフレーズの変更
特定のデータベーステーブルを反映
- ステージング環境で開発したWordPressプラグインやテーマをテストし、本番環境で特定のデータベーステーブルの更新が必要な場合
- ステージング環境で特定のデータテーブルを再編成したり、テーブルの問題を修正したりなどして、更新したテーブルのみを本番環境に反映したい場合
- ステージング環境でユーザー関連のデータやユーザー役割を変更し、ユーザーデータベースのテーブルだけを本番環境に反映したい場合
すべてを反映
※ステージング環境の作成後に本番環境のデータベースに加えた変更（コメント、新規コンテンツ、ECサイトでの注文、会員制サイトでの新規登録、フォーラムへの投稿など）は失われます。
- アップロードされたメディア（画像や動画など）を含む新たなコンテンツの作成
- カスタマイザーとテーマファイルの両方で行ったテーマの変更
- プラグインまたはプラグインの更新バージョンのインストールおよびテスト
ステージング環境を削除または更新する
ステージングサイトを削除するには、「WordPressサイト」＞（サイト名）に移動し、ステージング環境に切り替えます。ページの一番下までスクロールし、「環境の削除」ボタンをクリックします。
表示されるポップアップで、削除の対象をしっかりと確認した上で、サイト名の後にダッシュ（-）と「staging」という単語を加えた文字列（「サイト名-環境名」）を入力し、「環境の削除」ボタンをクリックすると削除が実行されます。
ステージング環境を最新のものに更新するには、それを一度削除した上で、新規環境を作成し、「方法1. 既存の環境を複製」を選択します。このようにしてステージング環境を作成すると、本番環境にある最新のデータベースとファイルが反映されます。
または、本番サイトのバックアップをステージング環境に復元することも可能です。この方法では、独自ドメインを追加していても削除されないため、ステージング環境を更新するたびに追加する必要はありません。
WordPressのバックアップをステージング環境に復元する
WordPressサイトのバックアップデータを既存のステージング環境に直接復元することもできます。WordPressのバックアップをステージング環境に復元する方法をご覧ください。※本番環境のバックアップをステージング環境に復元すると、すべてのステージング環境バックアップデータが存続します。
ステージング環境を再起動する
特定の状況において、サーバーのトラブルシューティングの一環として、ステージング環境が停止されることがあります。サイトへのアクセス時に「501 not implemented」「502エラー」または「521エラー」が表示された場合には、MyKinstaでサイトの「情報」画面移動して「（環境名）環境を開始する」をクリックし再開することができます。
ステージング環境を再開できない場合、またはMyKinstaにボタンが表示されない場合には、チャットにてカスタマーサポートまでご連絡ください。
プレミアムステージング環境を削除する
テストまたは開発が完了したら、プレミアムステージング環境を削除することができます。プレミアムステージング環境アドオンを使用している場合、アドオンの友好時のみご利用料金が発生します。プレミアムステージング環境を削除すると、アドオンも自動的に停止し、課金されることがなくなります。
WordPressホスティングプランのご利用開始から、30日以内にプレミアムステージング環境アドオンを削除した場合、日割り計算で料金が算出され、翌月のお支払い額に加算されます。WordPressホスティングプランのご利用開始から30日以上経過している場合は、現在の請求サイクルの残りの日数分の料金がアカウント残高にクレジットとして加算されます。このクレジットは、次回のお支払い料金と相殺されます。詳細については、WordPressホスティングの返金保証をご覧ください。
MyKinstaで、「WordPressサイト」画面開き、削除したい環境を選択します。
ページの一番下までスクロールし、「環境の削除」をクリックします。
表示されるポップアップで、削除の対象をしっかりと確認した上で、サイト名の後にダッシュ（-）と「staging」という単語を加えた文字列（「サイト名-環境名」）を入力し、「環境の削除」ボタンをクリックすると削除が実行されます。
プレミアムステージング環境が削除されると、MyKinstaの「企業の設定」＞「ご利用プラン」からアドオンの購読契約が自動的に削除されます。
注意事項
ステージング環境をお使いいただく上で、いくつか重要な注意事項があります。
1. ステージング環境のページキャッシュ設定
ステージング環境は開発、デバッグ、テスト用に存在するため、弊社のフルページキャッシュとOPcacheはデフォルトで無効になっています。ウェブサイトのスピードテストを実行すると、ページがキャッシュから配信されないため、平均よりも表示時間が長くなることが予想されます。ステージング環境でキャッシュを有効にするには、サイトのステージング環境の「ツール」画面で「キャッシュを有効にする」ボタンをクリックしてください。ステージング環境でキャッシュを有効にすると、「キャッシュをクリア」ボタンが表示されるようになり、キャッシュのクリアの際に利用できます。プレミアムステージング環境の場合は、CDNとエッジキャッシュも利用可能です。
2. ステージング環境のログイン情報
ステージング環境が本番サイトの複製である場合、ステージング環境を作成した後に変更しない限り、WordPressの管理者ログイン認証情報は本番環境とステージング環境の両方で同じになります。
3. SEO
デフォルトでは、ステージングサイトのインデックス登録はオフになり、本番サイトのSEOに影響を与えません。これは、WordPressの設定と、弊社の仕様により自動で追加されるHTTPヘッダーを組み合わせることで実現しています。
WordPressの設定は、ステージングサイトのWordPress管理画面で「設定」＞「表示設定」を開いて確認することができます。「検索エンジンでの表示」の横にある「検索エンジンがサイトをインデックスしないようにする」にチェックが入っているはずです。
弊社の一時URL（ステージングURLを含む）には、ボットのアクセスを制限するX-Robots-Tag: noindex, nofollow, nosnippet, noarchive HTTPヘッダーがあり、一時URLが検索エンジンによってインデックスされないことを意味します。このヘッダーは、一時URLまたはステージングURLから削除することはできません。削除が必要な場合は、独自ドメインを追加する必要があります。
4. プラグイン
CoScheduleやSocial Networks Auto Posterなどのソーシャルスケジューリングプラグイン（SNS投稿を自動化するもの）を使用している場合、ステージング環境では無効化することをお勧めします。有効にすると、ステージングURL（例：https://stg-sitename-environmentname.kinsta.cloud）からSNSへコンテンツが投稿され、分析データに歪みが出てしまう可能性があります。
Jetpackなどの特定のプラグインは、弊社のステージング環境を検知し、自動でステージングモードになり「あなたはステージングサーバー上でJetpackを実行しています/You are running Jetpack on a staging server.」というメッセージが表示されます。ステージングモードでは、WordPress.comにデータが渡されず、ステージングサイトを切断できない（本番サイトにつながる問題を防ぐため）ことを除いて、実質的にすべてが本番サイトと同じように動作します。
ドメインに紐付けるかたちでライセンスを獲得したプラグインについては、（弊社のステージングサブドメインではなく）独自ドメインの使用が必要になる場合があります。※ステージングサイトに独自ドメインを追加した後、プラグインライセンスの設定調整やプラグインのカスタマーサポートへの連絡が必要になる場合があります。
5. ログインURLのメモ
ステージング環境にサイトを複製し、デフォルトのログインURLを変更するWordPressプラグインを使用すると、URL中の変更を加えられた部分がステージング環境にコピーされます。例：http://staging-sitename-environmentname.kinsta.cloud/変更した部分
6. 開発およびテストに限定した使用
標準ステージング環境のワーカープロセス数は2つに限定されます。また、Kinsta CDNを有効にすることはできず、24時間使用されないと環境そのものがスリープ状態になることがあります。このような性質から、ステージング環境は開発およびテストにのみご利用ください。ステージング環境では（標準とプレミアムいずれも）本番としての使用は一切想定されていません。ステージング環境を本番サイトにご使用された場合、それに起因するいかなる問題についても弊社は責任を負い兼ねますので、あらかじめご了承ください。
7. プラン合計からのディスク容量の除外
できるだけ多くの容量をご利用いただけるよう、ステージングサイトは、お客様のプランにおけるディスク容量使用状況の計算時には一切加味されません。本番サイトのみがディスク容量のご使用分として考慮されます。
8. cronジョブ
本番環境のサーバーcronジョブはステージング環境では有効にならず（本番サイトをステージング環境に複製した場合でも）、本番サイトのcronジョブはステージング環境では実行されません。ただし、ステージング環境のcrontabを編集した上でステージング環境を本番環境に反映すると、本番環境のcrontabが上書きされます。
9. マルチサイト
WordPressのマルチサイトを運用している場合、マルチサイトの設定によってステージング環境と連動する場合としない場合があります。
- サブディレクトリを使用したマルチサイト（example.com, example.com/subsite1, example.com/subsite2）は、ステージング環境で問題なく機能します。
- サブドメインを使用したマルチサイト（example.com, subsite1.example.com, subsite2.example.com）は、サブサイトがHTTPSを必要としなければ問題なく機能します。
- HTTPS接続を必要とする場合は、ワイルドカードSSL証明書を導入した独自ドメインをステージングサイトに追加し、サブドメインにSSL証明書が適用されるようにする必要があります。これは、デフォルトのステージングURLに提供されるSSL証明書が、ステージングサブドメイン（例：stg-sitename-environmentname.kinsta.cloud）のみしか保護しないためで、追加のサブドメインレベル（例：subsite.stg-sitename-environmentname.kinsta.cloud）は保護されません。
- ドメインマッピングを使用したマルチサイト（example.com, example1.com, example2.comなど、完全に別のドメインのサブサイトを読み込む構成）─事細かな調整が必要
- 方法1─ドメインマッピングをオフにして、標準的なサブディレクトリ/サブドメインの設定を採用します（手作業でデータベースの検索と置換を実行）。
- 方法2─ドメインごとにステージングサブドメインを設定し、それらをすべてステージングサイトに追加します（同じく手作業でデータベースの検索と置換を実行）。
10. メール
ステージング環境では、デフォルトでメール送信（トランザクションメール）機能が有効になります。ステージングサイトで発生した注文に対し、ステージングサイトから関連するメールが送信される仕様です。ステージング環境からのトランザクションメール送信を希望しない場合は、Disable Emailsなどのプラグインを使用して、サイトからのメール送信を停止することができます。
よくあるご質問
時間割計算の料金システムについて教えてください。
プレミアムステージング環境アドオンのようなサービスの時間割計算とは、その月の請求サイクルで、プレミアムステージング環境が使用された時間に基づいて費用が計算されることを意味します。
時間割計算の例1
サイトに新たな機能を導入するため、利用しているプランをフル活用して導入テストを行いたい。プレミアムステージング環境を作成し、新機能を追加して、1時間テストを行うことに。問題なく導入ができたため、変更を本番環境に反映して、プレミアムステージング環境を削除した。
- プレミアムステージング環境の利用料金は、20ドル／月です。
- 30日の月の場合、請求サイクルを時間に換算すると合計720時間です。
30日 × 24時間 = 720時間 - つまり、1時間あたりの利用料金は0.03ドルとなります。
20ドル ÷ 720 = 0.03ドル - したがって、次回のご請求には、プレミアムステージング環境1時間分の利用料0.03ドルが加算されます。
時間割計算の例2
毎月の請求サイクルの途中でプレミアムステージング環境を購入し、請求サイクル終了日まで使用する場合には、半月分の使用料が請求されます（日割り計算で約10ドル）。
プレミアムステージング環境の名前は変更できますか？
変更可能です。変更したいステージング環境に切り替えて、「環境名」フィールドにある鉛筆のアイコン（編集）をクリックしてください。
変更後の名前を入力したら、「環境名の変更」ボタンをクリックします。
この方法で環境セレクタのドロップダウンに表示される環境名は変更されますが、環境作成時に生成された「kinsta.cloud」ドメインは影響を受けません。
ステージング環境にバックアップを復元できますか？
復元可能です。しかし、まずは標準またはプレミアムステージング環境の作成をお願いします。従来は、バックアップを復元する際に自動的にステージング環境を作成することができましたが、プレミアムステージング環境の導入により、現在は、バックアップを復元前にステージング環境の作成が必要になります。
また、本番環境の変更をステージング環境に反映することもできます。特定のファイルやデータベーステーブルだけを更新するには、選択的プッシュ機能を使用します。
プレミアムステージング環境にアクセスできるユーザーは誰ですか？
「サイトの開発者」と「サイトの管理者」は、作成済みのプレミアムステージング環境にアクセスすることができますが、新規作成または削除は行えません。「企業所有者」と「企業の管理者」のみ、プレミアムステージング環境の新規作成と削除が行えます。
ステージング環境はプランのディスク容量を消費しますか？
消費することはありません。できるだけ多くの容量をご利用いただけるように、ステージングサイトは、お客様のプランにおけるディスク容量使用状況の計算時には一切加味されません。本番サイトのみがディスク容量のご使用分として考慮されます。
ステージング環境でプラグインをテストし、ファイルのみを本番環境に反映した場合、プラグインに対応するデータベーステーブルは生成されますか？
本番環境にインストールしたことのないプラグインをステージング環境にインストールした場合、本番環境にファイルだけを反映しても、そのプラグインのデータベーステーブルは生成されません。
これは、プラグインでのいかなる設定も本番環境に反映されないことを意味します（設定が、JSONファイルのようなデータベース外のファイルに保存されている場合を除く）。
実際のプラグインがどのように構築されているかにもよりますが、本番サイトでプラグインを有効化する（必要に応じ、無効化した上で実行）と、データベース構造が作成されることがあります。
ファイルだけを本番環境に反映する場合、（ステージングにある）古いデータベースは本番環境のものを上書きしてしまうことはありませんか？
ファイルのみを反映する場合、データベースが上書きされることはありません。本番環境上のファイルのみが上書きされます。
ステージング環境でサイトのデザイン変更を行い、本番環境に反映しても、本番環境の新規加入者や顧客を失うことはありませんか？
変更がファイルに対してのみ行われる限り（プラグイン、テーマ、カスタマイザーの設定を含め、WordPress管理画面での変更がない場合）、データベースに影響を与えることなく、安全に反映できます。変更を本番環境に反映する際には、「ファイル」を選択し、「データベース」が選択されていないことをご確認ください。
ステージング環境から本番環境への反映時に、WooCommerceの注文やデータを除外したり同期させたりすることはできますか？
可能です。選択的プッシュ機能でステージング環境を本番環境に反映する場合、データベースが上書きされないようにファイルのみを反映することも、データベーステーブルを選択して特定のWooCommerceテーブルを除外することもできます。WooCommerceの各データベーステーブルに含まれているものに関してはこちらをご覧ください。反映すべきテーブルがわからない場合は、開発者に相談することをお勧めします。
マルチサイトを運営している場合、ステージング環境から本番環境に1つのサイトだけを反映できますか？
可能です。選択的プッシュ機能でステージング環境を本番環境に反映する際、サブサイトの1つのデータベーステーブルのみを選択してください。WordPressに含まれるデータベーステーブルの詳細はこちらをご覧ください。ファイルでは、pluginsとthemesフォルダはすべてのサイトで共有されますが、uploadsフォルダはサイトごとに分けることができるため、必要なサブサイトのアップロードだけを反映するように選択できます。反映すべきテーブルやファイルが不明な場合は、開発者に相談することをお勧めします。
サイトのPHPバージョンを変更するために選択的プッシュ機能を使用できますか？
使用可能です。PHPの新しいバージョンをテストするためにステージング環境を使用することはできますが、本番環境にその変更を加える準備を行なった後は、本番環境でその操作を行う必要があります。つまり、ステージング環境から本番環境への反映作業は不要です。以下の手順に従ってください。
- ステージング環境を作成します。
- ステージング環境を作成し、ステージング環境のPHPバージョンを変更します。
- ステージング環境で問題なく動作することを確認した上で（サイトのテストは十分に行なってください）、本番環境でPHPバージョンを変更します。
WordPress管理画面でCSSを変更し、ファイルを反映しました。キャッシュをすべてクリアしても変更が表示されないのはなぜですか？
変更の種類とその情報が保存されている場所によって、データベースを反映するか本番サイト上でその変更をあらためて実施する必要があります。例えば、WordPress管理画面のブロックやウィジェットでCSSを追加または編集した場合、おそらくデータベースに保存されます。
WordPress管理画面で何かを変更した場合、「テーマの編集」（「外観」＞「テーマの編集」）で行った変更を除いて、その情報は通常データベースに保存されます。
※ステージングサイトの作成以降、本番サイトのデータベースに対する変更は、コメント、新しいコンテンツ、ECサイトでの購入、会員制サイトでのサインアップ、フォーラムの投稿などを含むすべてが失われることになります。そのような場合には、データベースを本番サイトに反映するのではなく、本番サイト上で同じ変更を手動で行うことをお勧めします。
選択的プッシュ機能はマルチサイトでも使用できますか？
使用可能です。ファイルのみを選択すれば、マルチサイトの種類に関係なく、本番サイトに反映することができます。データベースのみ、またはデータベースとファイルの両方を選択する場合は、マルチサイトの設定によってはうまくいかない場合があります。
- サブディレクトリのマルチサイト（example.com, example.com/subsite1, example.com/subsite2）であれば、問題なく反映されます。
- サブドメインのマルチサイト（example.com, subsite1.example.com, subsite2.example.com）であれば、サブサイトがHTTPSを必要としない限り、問題なく反映されます。
- ドメインマッピングを利用したマルチサイト（example.com, example1.com, example2.comなどの、まったく異なるドメインに別のサブサイトを持っているもの）の場合、多くの手動での設定が必要になります。
- 方法1─ドメインマッピングをオフにして、標準のサブディレクトリ／サブドメインの設定に戻ります。データベース内の検索と置換を手動で行います。
- 方法2─本番ドメインごとにステージングサブドメインを設定し、すべてをステージングサイトに追加します。ステージング環境を本番環境に反映した後、手動でデータベース内の検索と置換を行い、各ドメインを更新します。