WP / MemberMouse / Discourse Integration Guide

So, this is a zillion times easier than it used to be!

add_user_to_discourse_group( $user_id, $group_names ) wants the WP userid? and the Discourse group name (no fussing in the json to figure out the group_id?!?!)?

Now I just need to find the $user_id and I’ll be golden.

Edit: $user = get_user_by('ID',$data["member_id"])

Edit: I’m all set! The version of the MemberMouse bundle-to-group function that I was working on yesterday was over 200 lines. The working version today is about 40.

Thanks again, @Simon_Cossar!

2 Likes

Great! I’ll document the changes to the functions soon. They take the same arguments as before, but behave a little differently. One thing to note is that Discourse will still consider the add_user_to_discourse_group and remove_user_from_discourse_group functions to be API calls - they are just making fewer API calls than the previous version did.

The functions return the status code that is returned from the Discourse request. You want to be getting a 200 response. If you’re adding a lot of users at the same time, you need to look out for 429 status codes and find some way of dealing with them. (When adding one user at a time it shouldn’t be an issue.)

4 Likes

Well, I’m pretty sure that last summer when I did this before there was a lot more that I had to do with my own darn API calls. This is pretty great. Hooray that this is now your day job!

1 Like

Maybe you can write a new and improved MemberMouse guide, Jay, when this is all said and done. :slight_smile: Come to think of it, just a general, “hook Discourse up to your membership plugin” guide would be great for ANY membership plugin. I’m guessing they all have similar “hooks” as MemberMouse.

4 Likes

@pfaffman, on a related topic. For a while now, the activate and deactivate API calls haven’t been working for us. I’m using them like so:

https://FORUM-URL/admin/users/DISCOURSE-USER-ID/activate.json?api_key=API-KEY&api_username=system

https://FORUM-URL/admin/users/DISCOURSE-USER-ID/deactivate.json?api_key=API-KEY&api_username=system

Have you had any luck with these calls lately? They used to work, I believe.

In my last Membermouse gig, I used only WPDiscourse\Utilities\Utilities::add_user_to_discourse_group( $user_id, $group_name );, which seemed to create and activate users. I didn’t test carefully that users were being deactivated, though for that job removing users from groups, I believe was all that was required.

In GitHub - pfaffman/discourse-user-creator: Create an activated user, optionally assigning to group I PUT those urls to deactivate and then activate. I’m 90% sure that it was working in the last couple weeks when I worked with someone who wanted to create users, assign passwords, and activate them without user intervention.

4 Likes

That’s good to know. I suspect it’ll be handy to have a separate way of activating/deactivating that doesn’t involve creating a user at the same time. (Like when people’s memberships lapse and then they rejoin.) I’ll let you know if I come up with anything that works.

2 Likes

Lots of good info here. I’ve been able to replace some bulky API code with more direct/compact functions.

@Simon_Cossar, I happened to notice something. When I use the function:

$response = WPDiscourse\Utilities\Utilities::get_discourse_user($userid);

It works great EXCEPT if the user is deactivated in Discourse in which case it returns an error. It seems to me that you should still be able to get info about a user even if their status is deactivated.

Thanks for all your hard work on this WP/SSO/Discourse stuff!

3 Likes

@pfaffman, that activate/deactivate API does actually seem to work after all. But oddly I also get an AJAX error which causes a bit of an issue for us:

"You are not permitted to view the requested resource."
"invalid_access"

Have you found any other way to activate/deactivate? I tried sync_sso_record passing in 'active' => 'false' but no dice. Also tried 'active' => 0.

Just curious.

No, but if you log them out of Discourse (there’s some path to do that) and they can’t log in through WordPress, deactivation shouldn’t be necessary, as they can’t log in, which is the point, right?

The users that I added with the sync_sso_record were all activated, so that shouldn’t be a problem either. I think.

1 Like

Canceling their WordPress account doesn’t log them out of Discourse so theoretically they could keep using Discourse as long as their Discourse login cookie stays in place. But I think you’re right that there is some way do purposely log them out of Discourse upon cancellation.

But more importantly to me is they will continue to get Discourse’s emails (Summary emails, Private Message notifications, @username mentions, etc.) unless you deactivate them in Discourse. So there needs to be some sort of proactive way to deactivate them.

2 Likes

Oops. Right. I probably need to fix that. I just hope I can remember who it was for. :wink:

@Simon_Cossar, is there a deactivate hook in wp-discourse, or do we need to do this with an API call?

There’s no way to deactivate a Discourse user through the plugin. It looks like a PUT request to /admin/users/$user_id/deactivate should do the trick.

3 Likes

I tested this out. It is returning deactivated users for me. What it won’t return are users who don’t have a SingleSignOnRecord associated with them. If you have created a user through the API, and that user has never logged into Discourse, they won’t be returned. If you pass the true parameter to the function after the user_id parameter, it will try to look up the user by their email address if it can’t find them by their external_id. That should work for all users. The problem with doing this is that it’s making 2 API calls.

A better solution is to use the newly rewritten add_user_to_discourse_group function, or the sync_sso_record function, for creating users. It’s more efficient, and you can be sure that the user has an external_id associated with them.

4 Likes

For anyone reading this, a much simpler way to do the auto-redirect is spelled out in the 14th post in this thread:

3 Likes

@lkramer, thank you for this guide and thread. I am attempting to configure MM and Discourse today but have a basic question.

The sales page for my forum is at domain.com/forum however Discourse is installed at forum.domain.com

Can I use MemberMouse on my Wordpress site (domain.com) to grant Access to the Discourse install on the forum subdomain? The forum subdomain only has Discourse, nothing else (different server).

Where do I need to authorize the MM plug-in to work? I assume domain.com

Thank you!

1 Like

Hey Casey, that setup (forum at forum.domain.com and main site at domain.com) sounds pretty standard, so I think installing and configuring WP Discourse + the above guide for syncing up w/ users’ memberships should should get you most of the way there.

I’ve done a similar setup with WP and I think this should work well for you, though I don’t have experience with MemberMouse specifically. If there’s something slightly different you’re trying to do from everything described above, or you get stuck with something along the way, holler!

1 Like

What I’m understanding is that the SSO function is really what gives MM + Discourse it’s link.

When a prospect buys membership via MM, a new WP user is created and then the functions above create a new Discourse user. Similarly, when a membership lapses (non-payment), MM deactivates the WP user and the functions above deactivate the Discourse user.

I’ve gotten SSO configured and created my own plugin for the functions to sit inside.

I’ve run into a few snags. In @lkramer’s post, she mentions the following in Step 2:

So you need add this line to the file /lib/discourse-sso.php in public function __construct( $wordpress_email_verifier ):

I cannot find that file. Here’s what I’m seeing:

(Note: the lib/sso folder is empty)

I did find lib/email-notification.php, which has this line:
/**
* EmailNotification constructor.
*/
public function __construct() {
add_action( ‘init’, array( $this, ‘setup_options’ ) );
}

Is it necessary to change this line? I assume I need to add this new “add_action” from Leah here, then add the scripts below to functions.php, but am not sure that script should go inside this “EmailNotification” bit.


Next major question: Inside Step 4, there are 4 bullets (Use the Discourse API to get the user’s Discourse username), Map their MM Membership ID to equic Discourse group ID, Sync up their user/email if they get changed in WO, Activate/deactivate Discourse users depending on status in MM).

I have a brand new site without any users, aside from Admin.

This seems quite involved. I’m getting outside of my comfort zone (ha! I’ve been outside it for awhile now!).

Questions:
1.) Is anyone able to share how they have these four pieces configured?
2.) Is the #marketplace the right place for me to post to hire someone to do this?

Thanks for all the help. Y’all are the best.

Hey Casey, I found discourse-sso.php in the sso-provider folder.

But to be honest, Id’ also love some help to configure the Step 4… :sweat_smile:

I must have missed reading that when I first read the guide. Under some circumstances it could make sense to directly edit a plugin’s files, I would not recommend this for most sites that are using the WP Discourse plugin - especially making changes that are related to SSO login. The best approach for extending a plugin is to rely on the action and filter hooks that exist in the plugin. I will add hooks to the plugin if adding them will prevent people from overwriting the plugin’s code. I’m wondering if there is a hook that could be added to the plugin here so that people don’t have to overwrite the plugin’s code.

4 Likes