@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 https://github.com/pfaffman/discourse-user-creator 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.
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.
Lots of good info here. I’ve been able to replace some bulky API code with more direct/compact functions.
@simon, 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!
@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.
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.
Oops. Right. I probably need to fix that. I just hope I can remember who it was for. 
@simon, 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.
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.
For anyone reading this, a much simpler way to do the auto-redirect is spelled out in the 14th post in this thread:
@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!
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!
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… 
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.
@lkramer would it be possible to share the code for the custom functions you created?
add_action(‘mm_member_membership_change’, ‘run_discourse_sync_based_on_mm_acct_change’);
add_action(‘mm_member_status_change’, ‘run_discourse_sync_based_on_mm_acct_change’);
add_action(‘mm_member_account_update’, ‘run_discourse_sync_based_on_mm_acct_change’);
