Integration von Discourse mit MemberMouse

[lkramer (Leah Kramer)]

Ich betreibe Discourse und MemberMouse auf 2 Websites. Hoffentlich ist dieser Leitfaden für andere hilfreich. Ihre genauen Spezifikationen können von meinen gewünschten Ergebnissen abweichen. Dieser Leitfaden geht davon aus, dass Sie mit den MemberMouse Hooks, Filtern und der MemberMouse PHP-Schnittstelle vertraut sind. Außerdem wird vorausgesetzt, dass Sie selbstbewusst benutzerdefinierten Code über functions.php oder Ihr eigenes benutzerdefiniertes Plugin zu WordPress hinzufügen können.

Dieser untenstehende Leitfaden beschreibt, was wir hinzugefügt haben, um Folgendes zu erreichen:

• Aktivieren/Deaktivieren des Benutzers in Discourse in Abhängigkeit von seinem Mitgliedschaftsstatus in MemberMouse
• Festlegen von Discourse-Gruppen, die MemberMouse-Mitgliedschaftsstufen repräsentieren
• Synchronisierung von Änderungen an Benutzernamen/E-Mail in Echtzeit
• Und diverse andere hilfreiche kleine Anpassungen

Schritt 1: Installieren Sie Discourse, WordPress und das WordPress-Plugin wp-discourse

Richten Sie WordPress, Discourse und das WordPress-Plugin wp-discourse ein und konfigurieren Sie sie ordnungsgemäß, wobei WordPress als SSO-Anbieter dient. Es gibt dazu viele Threads hier.

Schritt 2: Aktivieren Sie die Option, damit das wp-discourse-Plugin einen neuen Benutzer in Discourse erstellt, wenn ein Benutzer in WordPress erstellt wird

Ich stellte fest, dass das wp-discourse-Plugin einen Benutzer in Discourse erst dann erstellt, wenn ein Benutzer in WordPress erstellt wird, wenn ich eine Code-Änderung im Plugin vornehme. Dies liegt daran, dass das Plugin auf der Aktion „wp_login" basiert, sich jedoch in MemberMouse anders verhält als das normale WordPress-Verhalten. Sie müssen daher diese Zeile in die Datei /lib/discourse-sso.php in der öffentlichen Funktion __construct( $wordpress_email_verifier ) hinzufügen:

add_action( 'my_mm_account_added', array( $this, 'create_discourse_user' ), 10, 2 );

Und in functions.php oder Ihrem eigenen Plugin fügen Sie hinzu:

function add_user_to_discourse($data) {
	do_action( 'my_mm_account_added', $data["username"], get_user_by('ID',$data["member_id"]) );	
}
add_action('mm_member_add', 'add_user_to_discourse');

Schritt 3: Wenn gewünscht, stellen Sie sicher, dass neue Benutzer keinen Discourse-E-Mail-Aktivierungslink anklicken müssen

Standardmäßig sendet Discourse eine Aktivierungs-E-Mail an den neuen Benutzer, aber ich habe dies deaktiviert, da der Benutzer in WordPress bereits eine ausreichende Anzahl von Hürden überwunden hat, um beizutreten. Wenn Ihre WordPress-Website eine niedrige Einstiegsschwelle hat, möchten Sie die Aktivierungs-E-Mail möglicherweise nicht überspringen. In unserem Fall müssen Sie jedoch bezahlen, um beizutreten. Fügen Sie dies zu functions.php oder zu einem speziellen Plugin hinzu, das Sie erstellen.

add_filter( 'wpdc_auto_create_user_require_activation', 'my_wpdc_auto_create_user_require_activation' );
function my_wpdc_auto_create_user_require_activation( $require_activation ) {
    return false;
}

Schritt 4: Immer wenn eine Kontoveränderung bei einem MemberMouse-Benutzer auftritt:
Ordnen Sie MemberMouse-Mitgliedschaftsstufen Discourse-Gruppen zu
Synchronisieren Sie die E-Mail-Adresse/den Benutzernamen
Aktivieren/Deaktivieren Sie den Benutzer in Discourse entsprechend

Sie können dies zu functions.php oder Ihrem eigenen Plugin hinzufügen.

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');

In der Funktion run_discourse_sync_based_on_mm_acct_change möchten Sie:

(1) Die Discourse-API verwenden, um den Discourse-Benutzernamen (kann aufgrund der eigenen Benutzernamenregeln von Discourse leicht von dem in WordPress abweichen) und die Discourse-ID dieses Benutzers zu erhalten. (Dokumentation)

(2) Ordnen Sie Ihre MemberMouse-Mitgliedschaftsstufen-ID der entsprechenden Discourse-Gruppen-ID zu und setzen Sie dann Ihre Gruppe in Discourse. Zuerst müssen Sie Ihre alte Gruppen-ID löschen. (Dokumentation). Anschließend können Sie die neue Gruppe festlegen. (Dokumentation)

(3) Synchronisieren Sie Ihren Benutzernamen und Ihre E-Mail-Adresse, falls diese in WordPress geändert wurden. Wir erlauben nur Änderungen dieser Daten in WordPress. Ich habe hier Hilfe für diesen Teil erhalten.

(4) Aktivieren/Deaktivieren Sie den Benutzer in Discourse in Abhängigkeit von seinem Status in MemberMouse. Aktivieren (Dokumentation). Deaktivieren scheint in der API-Dokumentation zu fehlen. $url = $url_base.‘admin/users/’.$discourse_userid.‘/deactivate.json?’.$api_auth;

Schritt 5: Automatisches Umleiten zurück zu Discourse, wenn angemessen

(Ich empfehle dringend, diesen Teil erst zu behandeln, wenn Sie ein sehr gutes Gefühl dafür haben, wie WordPress und Discourse zusammenarbeiten.)

Wenn ein Benutzer NICHT in Discourse und NICHT in WordPress angemeldet ist. Und er kommt zu einer URL in Discourse und klickt auf den blauen Login-Button, wird er zu WordPress weitergeleitet, um sich anzumelden, aber dann leitet MemberMouse den Benutzer zu der Seite weiter, die in den MemberMouse-Einstellungen für die Weiterleitung festgelegt ist. Der Benutzer wird leider nicht zurück zu Discourse weitergeleitet. So habe ich dies gelöst. Sie können dies zu functions.php oder Ihrem eigenen Plugin hinzufügen. (Thread für weitere Informationen.)

// Wenn die Person vom Discourse-Forum kam, leiten Sie sie genau dorthin weiter, wo sie war, nachdem sie sich angemeldet hat
function my_mm_login_redirect( $infoObj ) {
	if ( @$_COOKIE['detected_forum_referal'] != '' ) { // Sie müssen dafür sorgen, dass dieses temporäre Cookie gesetzt wird, wenn die Person gerade über Discourse eingetroffen ist
		$current_user       = $infoObj->user;
		$user_id            = $current_user->ID;
		// Payload und Signatur.
		$payload = @$_COOKIE['mm_cookie_sso'];
		$sig     = @$_COOKIE['mm_cookie_sig'];
		// %0B zurück zu %0A ändern.
		$payload = rawurldecode( str_replace( '%0B', '%0A', rawurlencode( $payload ) ) );
		// Signatur validieren.
		$sso_secret = 'YOUR-SSO-SECRET';
		$sso        = new \WPDiscourse\SSO\SSO( $sso_secret );
		if ( ! ( $sso->validate( $payload, $sig ) ) ) {
			return '';
		}
		$nonce  = $sso->get_nonce( $payload );
		$params = array(
			'nonce'               => $nonce,
			'username'            => $current_user->user_login,
			'email'               => $current_user->user_email,
			'external_id'         => $user_id,
		);
		$params = apply_filters( 'wpdc_sso_params', $params, $current_user );
		$q = $sso->build_login_string( $params );
		do_action( 'wpdc_sso_provider_before_sso_redirect', $user_id, $current_user );
		// Zurück zu Discourse weiterleiten.
		return('YOUR-FORUM-BASE-URL' . '/session/sso_login?' . $q);
	}
	return('');
}
add_filter( 'mm_login_redirect', 'my_mm_login_redirect', 10, 1 );

[shim (john shim)]

if i May ask do you need to install the Discourse on its own or … you just need the discourse plugin in your wordpress

[lkramer (Leah Kramer)]

You need to install Discourse on it’s own. The plugin just helps WordPress and Discourse talk to each other.

[shim (john shim)]

thank you m new here and i like this community so im in a process on launching it on my Google cloude…

[andrec (André)]

@lkramer - how does this workflow need to change to use MemberMouse Bundles instead of the MM membership status?

(For us MM memberships are too limited, as a customer can only be in one at a time (free or paid). We have many products, so we use Bundles which allows us infinite flexibility.)

Our use case is as follows:

We sell multiple courses. We control course access using Bundles. “Product 1 Bundle” and “Product 2 Bundle,” etc. Any one customer can have access to one or many (or all) of course courses.

Within Discourse we have a separate course forum (category/group) for each product…

We want customers of “Product 1 Bundle” to only be able to see the Discourse category/group for that course, and so on.

Any idea how your workflow would need to change to allow for our use case?

Thx a ton in advance, Leah!

[lkramer (Leah Kramer)]

In order to rely on bundles rather than membership levels – anywhere I mentioned membership status/level, you’d just check the person’s bundle status via a MemberMouse php function. So check whether they have bundle X and whether it’s currently ‘active’ and if so, put them in Discourse group X or else remove them from group X. I believe the MemberMouse php function you want is something like this:

if ( mm_member_decision(array("hasBundle"=>"1")) )

Now, regarding only making certain Discourse categories accessible to certain Discourse groups, I’ve never tried it but according to this thread here you can restrict categories to certain groups:

Is it possible to restrict categories to specific groups of vetted users?

Hello! I would like to use discourse to build a community for information security professionals and novices. Some of this would involve sharing sensitive information, but only with users that have been vetted, and can be trusted, Is there any way to restrict categories to specific users. Apologies if this question has been asked before. I searched, but could not find anything.

So as long as you can successfully set/unset a person’s Discourse group based on their bundle (which should be do-able), then you can achieve your goal of only having access to certain categories.

[lkramer (Leah Kramer)]

Another tidbit of potentially helpful info – To learn to use the Discourse API, write some small isolated scripts to get small pieces working as a proof of concept and to know exactly what code works. There are often several ways to interact with an API even within one language. So, e.g, write a little script that just tests the concept of setting and unsetting someone’s Discourse group. This is what I did and then I knew it was safe/reliable to add them into the MemberMouse eco-system where approprirate.

[riking (Kane York)]

The best way to sync group membership is, of course, the sync_sso and during SSO login (which should go through the same function!! you don’t want to add someone from a group and take them back out when they log in) — because this is way more efficient, only 1 API call to change as many groups as you want.

[andrec (André)]

Thx @lkramer! (and @riking)

[lkramer (Leah Kramer)]

Thx @riking. So are you saying you can set/unset multiple groups in sync_sso. That’s good to know.

[pfaffman (Jay Pfaffman)]

@lkramer

add_action( ‘my_mm_account_added’, array( $this, ‘create_discourse_user’ ), 10, 2 );

This wasn’t working for me, and I just upgraded, and now there is no create_discourse_user, it seems.

@simon, have you got a suggestion here?

It seems that having to edit the plugin to make membermouse work is something of a bummer. I think that I can imagine code that would solve that if I first could get WordPress to trigger creating the account.

[simon]

@pfaffman

This wasn’t working for me, and I just upgraded, and now there is no create_discourse_user, it seems.

It’s still there: https://github.com/discourse/wp-discourse/blob/master/lib/utilities.php#L306

You need to call it with the namespace WPDiscourse\Utilities\Utilities::create_discourse_user( $user )

There is also a sync_sso_record function that would be better to use if you are able to. It takes an array of sso parameters as an argument. You can get them from the get_sso_params function.

I’m in the process of cleaning up this file. I won’t remove any functions that I’ve posted about on meta. If I break anything, let me know.

Edit: I read the OP more closely. I hadn’t realized it was editing the plugin’s code. That part will be broken by the most recent update. It would be better to call either the create_discourse_user or the sync_sso_record function from WPDiscourse\Utilities, and add the my_mm_account_added hook to your functions.php file or a separate plugin.

[pfaffman (Jay Pfaffman)]

Thanks, @simon!

Here’s what I’m doing now:

function add_user_to_discourse($data) {
	do_action( 'my_mm_account_added', $data["username"], get_user_by('ID',$data["member_id"]) );
    error_log ("Doing add_user");
}

add_action('mm_member_add', 'add_user_to_discourse');

Also, I have a handful of actions like

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');

Should all of these call sync_sso_record? And what should go in $user when I call WPDiscourse\Utilities\Utilities::create_discourse_user( $user )? (I’m going to RTFC now, but perhaps your 2 minutes can save me an hour. )

Edit: OK, should something like this work? I see that it’s getting called, but the user’s not getting created.

function add_user_to_discourse($data) {
    $user['name'] = $data['first_name'] . " " . $data['last_name'];
    $user['user_email'] = $data['email'];
    error_log ("Calling create_discourse_user");
    WPDiscourse\Utilities\Utilities::create_discourse_user( $user );
}

[simon]

Assuming you are also adding the user to a group, I think you could just call WPDiscourse\Utilities\Utilities::add_user_to_discourse_group( $user_id, 'group,names' ). That gets the sso params for then calls sync_sso_record with the params. The remove_user_from_discourse_group function works in a similar way, except it removes users from a group or groups.

If you just want to create or update a user without dealing with groups, you can do something like this:

$user = get_user_by( 'id', 1 ); // Supply user_id here.
$sso_params = WPDiscourse\Utilities\Utilities::get_sso_params( $user );
WPDiscourse\Utilities\Utilities::sync_sso_record( $sso_params );

If SSO is enabled, I don’t think there would be a reason to prefer the create_discourse_user function over the sync_sso_record function. If you do need to use it, it takes a WordPress user object as the argument: $user = get_user_by( 'id', 1 );

[pfaffman (Jay Pfaffman)]

@simon

Assuming you are also adding the user to a group, I think you could just call

Yeah. Sadly, I started with code that was written before add_user_to_discourse_group existed. I was just wondering whether I should change my working API calls to use that instead.

It’s not obvious to me that add_user_to_discourse_group will create the user. Is that happening somewhere that I don’t see?

[simon]

@pfaffman

It’s not obvious to me that add_user_to_discourse_group will create the user. Is that happening somewhere that I don’t see?

Yes, it creates a user by sending the SSO parameters to the Discourse /admin/users/sync_sso route. It actually takes a comma separated list of group names as its argument (no spaces between names), so it should be renamed. You can also call it with an empty string as the group_names argument. You have to at least supply an empty string for the group names, or it will throw an error.

[pfaffman (Jay Pfaffman)]

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!

[simon]

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.)

[pfaffman (Jay Pfaffman)]

@simon

Great! I’ll document the changes to the functions soon. They take the same arguments as before, but behave a little differently.

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!

[lkramer (Leah Kramer)]

Maybe you can write a new and improved MemberMouse guide, Jay, when this is all said and done. 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.