tl;dr - When a new WordPress user places an order or signs up, they appear to somehow be overwriting or connecting with existing users in Discourse. Not sure how to troubleshoot.
- We are using the wp-discourse plugin for SSO where Wordpress is the DiscourseConnect Provider.
- We launched our Discourse community, hosted on a Digital Ocean droplet
- When we launched the discourse community and connected to SSO with the wp-discourse plugin, we were hosting WordPress on AWS Lightsail, using Plesk as our control panel
- We migrated to Nexcess WordPress managed hosting, earlier this year and the Discourse connector seemed to remain intact.
- We did not migrate our users when we moved to our new WordPress installation. They were exported, and we plan to import them soon.
- Our WordPress site has been closed down for a bit as we’ve been making some big adjustments
Over the past few months, we’ve had a lot of people placing orders on WordPress (WooCommerce), and we noticed something peculiar… that when you look at a user account in WordPress and look at the Discourse Username field, that their username is showing as those of existing users from Discourse. Somehow our connection to Discourse seems to be messed up. A user just signed up today and their Discourse Username is tennisdpm which you can see is an existing user, who signed up back in 2020.
We are soon going to be migrating (adding) all of the users who had accounts on our old WordPress instance, and adding them to our new instance, but seeing how there seems to be some conflict with existing users and new users signing up, we want to had a plan of action that would prevent continued conflicts and sync existing WP users (via email as unique identifier) with Discourse users, and provision new SSO Discourse accounts, when new WP users come on board.
Would really appreciate some help and direction on how we should proceed!
Existing wp-discourse connect SSO settings:
Sounds like your new WP users are getting user IDs which correspond to existing DiscourseConnect External IDs.
Oh my!! Thanks for the heads up @omarfilip! Is there a way to reset this or prevent this from continuing to happen? Or maybe we could/should turn this off until we’re done migrating all former users.
I’m really not sure what the best way to approach it would be. How many records are there that need to be fixed?
We have about 80 users in WP right now that need to be “detached” from the current Discourse users with whom they seem to be associated. Then we also have about 750 users that we need to import, from our old instance, and be sure they are not having the same issue that we’re having right now.
I was hoping that accounts in WP were linked with Discourse account based on email address as the unique identifier… not external/user IDs.
Hey @jord8on, the way the matching works on the discourse end of things is that it first tries to match the external id (which in your case now point to different users as you’ve changed your Wordpress database), and then tries to match using the email address. There are some good reasons for using ID first. Email is not a great decentralised identifier.
So what you need to do is delete the single sign on records in discourse created when you were using your old wordpress database. You can use a datetime to identify them, e.g. you’d do something like this on your discourse instance
./launcher enter app
SingleSignOnRecord.where("created_at < ?", 1.month.ago) // check if this matches your expectations
SingleSignOnRecord.where("created_at < ?", 1.month.ago).delete_all
The old users being imported to the new db will be matched on the basis of email to their existing discourse accounts (as their new wordpress id won’t match any sso records).
I would also remove all
discourse_username data on wordpress and let it be automatically re-synced via the user webhook. You’ll need to run this (perhaps using WP CLI), which deletes all entries for the
discourse_username meta field.
delete_metadata( 'user', 0, 'discourse_username', '', true );
For future folks reading this, if you use DiscourseConnect with one Wordpress database, then move to an entirely new Wordpress database without a migration, you’re going to have this kind of issue. You should seek assistance before doing this kind of change.