Hi Eva, I went over your code and there’s no errors that I can spot - and I totally get your frustration. If it hadn’t been for Simon Cossar I don’t know how I’d have resolved it myself.
So, taking it backwards: if the PHP is correct, then something else must be disconnected. (browniepoints for me, yay.)
I don’t know enough about any of that to be able to give suggestions or help.
If you’ve got your forum parked with the boys from Discourse Hosting, you could ask Richard (his name tag won’t pop, but this is his profile: Profile - RGJ - Discourse Meta )
Or perhaps @simon might be able to provide you with the missing steps.
Keeping my fingers crossed for you.
p.s. these are all the related plug-ins i use (+ that PHP one)
(Memberpress Drip is email marketing, so not related to this)
groups are any and all: closed and opened (i don’t give access to hidden groups, come to think of it)
these are some of the group names as displayed in ‘Groups’ - and as you can see, the “NoSpacesNames” are the ones that coincide with the PHP settings
If by parameters you mean the following, then no:
nor in the actual group settings (where you create it, with name, owner, etc.), it’s all straight forward and not connected to accessing through SSO - so setting or not setting this as a person’s primary group is not relavant.
There is one webhook here on Discourse that I put in as instructed by the WP-Discourse plugin:
email verification technically goes via memberpress: they (my wp-instance) send the log-in details to the user. by clicking the log-in link the users verify their address.
i know for a fact that it’s not through Discourse, because for a while it ALSO went through discourse (glitch somewhere) and Richard sorted that for me.
I haven’t looked at it for a while, but what you would need is a communication between your Discourse codes and your Payment codes (in my case: memberpress).
So if the person stops paying, memberpress changes their code, and this code corresponds to a different group level.
If there’s no link with the payment then the group level will not be adjusted.
Re-reading your question: i’m not sure how it works with trust levels…
but… if all else fails, you can easily create a GROUP that is set to trust level 2 and another that is set to trust level 1 and have your membership plug in assign those groups to your members.
hope that helps. if not, i’ll have to dive back in. it’s been up and running since the previous conversation and i’ve never looked at it since.
This came up in another post on Meta today, so I had a look at the code to confirm whether or not a user’s trust level can be reduced by adding them to a group that sets a lower trust level than the user’s current group. From looking at the code, I can see that this is not possible:
if @user.trust_level < @trust_level
If a user’s trust level is lower than the trust level that is granted by the group, adding the user to the group will update their trust level. Otherwise, there will be no change in the user’s trust level.
i’m a little rusty (also, it’s late) but the trust level wouldn’t really be relevant. i don’t use trust levels at all. Group TL 2 has access to ‘this’ and Group TL1 does not.
the actual trust level is not in use. any member can be trust level 1 and still gain access (through payment) to Group TL 4 - provided I do not set permission to trust levels, but only to groups.
If a user is updated through the normal SSO login process the update will not occur until they logout and log back in again. The code example above is the easiest way to approach the problem, but it’s probably not the best way to manage group membership.
The WP Discourse plugin has a couple of helper functions that are enabled when WordPress functions as the SSO provider site for Discourse. These functions allow you to update group memberships without requiring the user to logout of Discourse. Those functions are in the topic that Richard linked to: Managing Discourse group membership with WP Discourse SSO.
The post that Richard linked to gives some details about the two different approaches. I’m going to add those details to the #howto topic next week. For now it would be good to read through the post.
Sure, the topic is here: Managing Discourse group membership with WP Discourse SSO. It describes how to use the WP Discourse add_user_to_discourse_group and remove_user_from_discourse_group functions. Assuming that you have your WordPress site configured to be the SSO provider site for Discourse, those are the functions that you should use to manage group memberships on Discourse.
The example that topic uses is with the PaidMembershipsPro plugin, but a similar approach should work with any well made WordPress membership plugin.
I’m going to add some details to the topic about how to manage group membership with the add_groups and remove_groups SSO parameters. For most cases, managing group membership by adding those parameters to the SSO payload will not be the best approach, because it requires users to logout and log back into Discourse before their group membership will be updated.
My hope is that in the near future there will be an out-of-the-box solution for linking Discourse with specific WordPress membership plugins. Currently it can only be done by adding a small amount of custom code to your WordPress site. If this isn’t something that you normally do, you may need to hire a developer to help with this.