WPサイトの数ヶ月前のステージングコピーがあります。フォーラム（サインアップは停止しており、まだ公開されていません）でSSOがどのように機能するかを試してから、後で、その間にユーザーがもう少し追加される本番サイトに接続しようと考えていました。これはDiscourseを混乱させますか？ステージングの数人のユーザーでどのように機能するかを試しますが、接続が別のサイトを使用するように切り替わった場合、それらのユーザーはどうなりますか？ただし、WPのユーザーIDとメールアドレスは同じままです。
「いいね！」 1
WordPressのユーザーIDとメールアドレスが本番サイトとステージングサイトで同じであれば、Discourse側で何も変更せずに本番サイトに切り替えることができます。
ただし、ユーザーIDが同じであることを再確認することをお勧めします。WP Engineのステージングサイトと本番サイトでは、ユーザーIDが一致することが保証されておらず、完全に別のデータベースを使用していたことを思い出しました。本番サイトとステージングサイトでそのようなことがないことを確認してください。
本番サイトとステージングサイトでユーザーIDが一致するかどうか不明な場合、かつ、SSOペイロードでrequire_activationパラメータがtrueに設定されていない場合は、本番サイトに切り替える前にDiscourseデータベースからすべてのSingleSignOnRecordエントリを安全に削除できます。既存のユーザーがWordPress経由でDiscourseに初めてログインする際に、Discourseはメールアドレスに基づいてユーザーを見つけ、新しいSingleSignOnRecordを生成します。
既存のSingleSignOnRecordエントリは、Railsコンソールから以下のように削除できます。
SingleSignOnRecord.destroy_all
SSOペイロードでrequire_activationパラメータがtrueに設定されている場合でも、Discourse側でSSOレコードを削除できます。既存のユーザーが本番サイトからDiscourseにログインできるようになる前に、WordPressでメールアドレスを検証済みとしてマークする必要があります。WordPressのプロフィールページからその方法の詳細はこちらをご覧ください: https://meta.discourse.org/t/validate-email-addresses-with-the-wp-discourse-plugin/130085。
ステージング用のWordPressサイトがある場合は、ステージング用のDiscourseフォーラムも用意することを強くお勧めします。そうすれば、ステージング用のWordPressを本番用のDiscourseに接続した場合に何が起こるか心配する必要がなくなります。
これはよくあるシナリオです。WordPressホスティングサービス（例えばWP Engine）でサイトを作成し、デフォルトのステージングサイトでテストしてから、本番環境に切り替えるというものです。Discourseのサポートをしていた頃、同じ質問に何度も答えました。Discourse用の永続的な別ステージングサイトは、一般的にオプションではありませんでした（そして、実際には必要でもありませんでした）。
「いいね！」 1
はい、おっしゃる通り、比較的よくあるシナリオです。
とはいえ、この方（@Firsh、もし間違っていたら訂正してください）のように、WordPressが本番環境にある場合、ステージング環境と本番環境を混在させる潜在的なリスク/コストは、単に別のDiscourseインスタンスを起動することによって節約できる時間とコストを上回ると私は考えています。これは、ステージングが本番環境のコピーである（これはよくあるケースです）という前提に基づいています。
新しいインスタンスを起動することに組織的な制限がない限り（その場合は、おそらく別途ステージング環境を用意すべきです）、DigitalOceanやVultrなどで別のDiscourseインスタンスを起動するのは比較的安価で簡単であり、ステージングと本番環境の相互汚染から生じる可能性のある問題を回避できます。そうすることで、時間（そして時間としてのコスト）を節約できる可能性が高いです。完了したらオフにすることができます。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.