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.
1 Like
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.)
1 Like
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.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.