I have a few months old staging copy of a WP site. I thought I’d try how the SSO works with the forum (closed for signups, not yet launched) and then later connect with the production site, which will have a bit more users added in the meantime. Would this confuse Discourse? I’d try with a handful of users from staging how things work, but what happens to them when the connection is switched to use the other site? Their WP user ID and email remain the same, though.
AI-generated summary
You can switch from a staging site to a production site as the provider for Discourse, but there are some considerations to be aware of. As long as the WP user ID and email remain the same, simon advises that you can switch without making changes on the Discourse end. However, if the user IDs may not match, you can safely delete existing SingleSignOnRecord entries before switching to the production site.
simon also provides instructions on how to delete existing SingleSignOnRecord entries from the Rails console and how to handle the situation if the require_activation parameter is set to true in the SSO payload.
angus suggests creating a separate staging Discourse forum to avoid potential issues with mixing staging and production environments. simon acknowledges this as a common scenario, but notes that a separate staging site for Discourse may not always be necessary.
angus counters that if your WordPress site is in production, the potential risks of mixing staging and production environments outweigh any time and cost savings, and recommends spinning up a separate Discourse instance to avoid issues.
If the WP user ID and email are the same on your production and staging sites, you can switch over to using the production site without having to make any changes on the Discourse end.
It would be a good idea to double check to make sure that the user IDs are the same though. I seem to remember that with WP Engine staging and production sites there wasn’t a guarantee that the user IDs would match between production and staging - they use completely separate databases. Make sure that isn’t the case for your production and staging sites.
If you aren’t sure that the user IDs will match between production and staging, and the require_activation parameter is not being set to true in the SSO payload, you can safely delete all existing SingleSignOnRecord entries from the Discourse database before switching over to the production site. The first time existing users login to Discourse via WordPress, Discourse will find them based on their email address and generate a new SingleSignOnRecord for them.
Existing SingleSignOnRecord entries can be deleted from the Rails console with:
SingleSignOnRecord.destroy_all
If the require_activation parameter is being set to true in the SSO payload, you can still delete the SSO records on the Discourse end. Before existing users can log into Discourse from your production site, you’ll need to mark their email addresses as verified on WordPress. Details about how to do that from their WordPress profile pages are here: Validate Email Addresses with the WP Discourse plugin.
If you have a staging Wordpress site I’d strongly recommend you also have a staging Discourse forum. That way you won’t have to worry about what might happen if you connect your staging Wordpress to a production Discourse.
This is a common scenario - someone creates a site on some WordPress hosting service (say WP Engine), tests things out on the default staging site, then switches over to production. I answered the same question multiple times when I was doing Discourse support. A permanent separate staging site for Discourse generally wasn’t an option (or really needed.)
Yes, you’re right, it is a relatively common scenario.
Nevertheless, if your Wordpress is in production, as seems to be the case with this chap (@Firsh please correct me if I’m wrong), then I think the potential risk / cost of mixing staging and production environments is outweighed by any time and cost saved by just spinning up a separate Discourse instance. This is assuming your staging is a copy of your production (which is often the case).
Unless there are organisational restrictions on spinning up new instances (in which case you should probably have a separate staging environment anyway), it’s relatively cheap and easy to spin up a separate Discourse on DigitalOcean, Vultr etc, and avoid any issues that might arise from Staging <> Production cross-pollination. You’ll probably save time (and money-as-time) in doing so. You can just turn it off when you’re done.