A couple of issues with WP Discourse and BuddyPress SSO


(MicroDonk) #1

I have a WP instance setup on one server and Discourse setup on another and have attempted to link them with the plugin. I am having two issues.

  1. When I logout of the admin account on Wordpress, and log back in, it creates a new user called User1 in Discourse with no email address and no access rights. The only way I can login to Discourse is to login to the command line and turn it off.

  2. When using BuddyPress to handle registration, it can’t detect that the email has been activated. When disabling BuddyPress and using the default WP registration process, it works. I am assuming I need to hook into the BuddyPress process and insert code, but I have no idea how to do so.

Thanks.


(Simon Cossar) #2

I’m assuming that you are using WordPress as the SSO provider for your Discourse forum.

Yes, this is how it should be working. My understanding is that BuddyPress doesn’t do any email verification when it registers a user. There are a few possible workarounds for this.

I don’t know what could be going on with that. Can you give any more details about your setup?


(MicroDonk) #3

Yes, you are right, I am using WP as the SSO provider. Let’s say my username on WP is Admin. My username on Discourse in the initial setup is also Admin. When I enable SSO, logout of WP, and log back in and visit Discourse, it creates a new user called Admin1 with no email, who is just a basic user. I have no way to access the admin backend at this point.

BuddyPress does send an email verification, but I guess it does it in a different way than Wordpress does by default. Any ideas on how to approach this?


(Simon Cossar) #4

Thanks. If BuddyPress is sending a verification email then it should be possible to use that to verify email addresses for Discourse.

I’m more concerned about the first problem for now. Have you enabled the wp-discourse SSO setting ‘Automatically create and login users.’?


(MicroDonk) #5

Yes, I have enabled that setting.


(Simon Cossar) #6

I mean this setting:

My guess is that what’s happening is that you are using a different email addresses for the admin accounts on WordPress and on Discourse. For example admin@website.com and admin@forum.com. Discourse is automatically creating a new user from your WordPress email address and has no way of knowing that it’s supposed to be an admin account.


(MicroDonk) #7

Yes, that is the setting I have enabled, and you are exactly right! The emails don’t match. Thank you very much.

Now, if I can get the Buddypress thing solved, I’ll be all set.


(Simon Cossar) #8

Great! I’m fairly sure that it’s the mismatched emails that are causing the problem, not the ‘Create Discourse User on Login’ setting. All it’s doing is initiating the login process.

I’m surprised that this hasn’t come up before. The easiest solution might be to delete the admin1 user on Discourse and then edit your email address on either Discourse or WordPress so that the email address for both admin accounts match. Then re-enable SSO and try again.

If you don’t want to edit your email addresses, a temporary solution would be to create a new user on your WordPress site using your Discourse email address and then use that WordPress account to log into your Discourse admin account.


(MicroDonk) #9

I just changed the email address to match, and all seems to be good. Thank you.


(MicroDonk) #10

Now all that remains is that I can’t get it to play well with the BuddyPress activation system.


(Simon Cossar) #11

BuddyPress does an action after a user clicks on the link in the activation email. Something like this added to your theme’s functions.php file will clear the ‘discourse_email_not_verified’ flag so that users can log into Discourse without having to respond to another activation email:

add_action( 'bp_core_activated_user', 'my_namespace_activate_user' );
function my_namespace_activate_user( $user_id ){
    delete_user_meta( $user_id, 'discourse_email_not_verified' );
}

I’ll look at this some more tomorrow, but it seems like it should be fine to use.


(MicroDonk) #12

Thanks! I’ll give it a shot.


(MicroDonk) #13

Unfortunately, the newly activated user still doesn’t show as email verified in the Discourse backend and can’t login.


(Simon Cossar) #14

It’s working like this for me:

  • a user registers through the BuddyPress signup form
  • they click ‘complete signup’
  • a notice appears saying they have created their account, but need to activate their account via the email they have been sent
  • they go to their email inbox and click on the activation link
  • they are now able to login to Discourse through SSO by either clicking on the login button on the forum, or by clicking on an SSO link that’s embedded in the WordPress site

The user won’t exist on Discourse until they have logged in.

When I add the function that I posted to my theme’s functions.php file, the user is able to log into Discourse without being sent an activation email from Discourse. Without that function, the user can still login, but first they will have to respond to an activation email that’s sent from Discourse.

If, on your site, users can log in, but are still getting an activation email from Discourse, check for copy-paste errors in the function I provided. If users can’t login at all through SSO, double check all your settings on Discourse and WordPress.

Let me know if this still isn’t working for you.


(MicroDonk) #15

Here is my functions.php in my child theme:

The workflow is as you describe, however, clicking the link in the email does not activate their account through Discourse. They can login to WP just fine.


(MicroDonk) #16

Nevermind, it was another plugin interfering. It is fixed now. Thank you for all of the help!


(Simon Cossar) #17

The functions.php file looks right. I see from your next post that everything now is working.

The only issue that I see with the code I supplied is that the prefix wpdc_ probably isn’t very good. The problem is that if a plugin on your site also used the function name wpdc_activate_user in the global namespace, your site would crash.

For most WordPress functions that I’ve added on this forum, I’ve prefixed them with my_namespace_, with the assumption that people will replace my_namespace_ with their namespace. I’m going to edit the code that I added to change the function’s prefix.