# WP (SSO) + LMS + Discourse Advice/Best Practices?

**URL:** https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502
**Category:** WordPress
**Created:** [September 3, 2019, 3:51pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502 "2019-09-03T15:51:21Z")
**Posts on this page:** 10
**Page:** 1

<div class="post-metadata">

### Author: ![TGP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgp/32/153649_2.png) [@TGP](https://meta.discourse.org/u/TGP)
#### Post date: [September 3, 2019, 3:51pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/1 "2019-09-03T15:51:21Z")

</div>

Hi!

I’m still reading through old threads on using WP SSO, but I was curious if sharing our roadmap might surface any advice. Are there things we should look out for? Things we should avoid?

**Our Stack:**

- WordPress (foundation)
- MemberPress (manages user accounts)
- LearnDash (LMS, course creation)
- Discourse (private, member community)

**Our Desired Onboarding Experience:**

1. Visitor arrives on our WP site (content marketing) & converts to paid member.  
– We’re thinking about a 24-hour free trial (w/ auto-conversion).
2. [WP Discourse](https://github.com/discourse/wp-discourse) plugin (SSO) generates Discourse account (TL0).
3. TL0 gets read-only access to the bulk of the categories.
4. TL0-1 promotion requires 5 minutes posting an introduction.
5. After 24hrs, member’s card is charged, membership is official, auto-promoted to TL1.

WP SSO would manage accounts so that only paid/current members have access to both community and LMS content.

**I’m curious if there’s either a simpler or better way to do this. Reducing new member friction is important, but so is ensuring longterm scalability, ya know?**

Appreciate any insights. Thank you.

---

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [September 3, 2019, 6:19pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/2 "2019-09-03T18:19:15Z")

</div>

From your onboarding list, it looks like you are hoping to override the Discourse trust level system. I think a better approach would be to use Discourse group membership to control access to your site’s content. For details about how this works, see [Understanding groups and category permissions](https://meta.discourse.org/t/how-to-use-category-security-settings-to-control-access-to-content/87678).

The [WP Discourse](https://github.com/discourse/wp-discourse) plugin has a couple of functions that you can use to add and remove users from groups. Details are in this topic: [Manage group membership in Discourse with WP Discourse SSO](https://meta.discourse.org/t/managing-discourse-group-membership-with-wp-discourse/74724). That topic uses the PaidMembershipsPro plugin as an example, but the same idea should work with MemberPress.

Another topic that may have useful information is [How to prevent some WP users from being able to login to Discourse](https://meta.discourse.org/t/how-to-prevent-some-wp-users-from-being-able-to-login-to-discourse/93234).

---

<div class="post-metadata">

### Author: ![TGP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgp/32/153649_2.png) [@TGP](https://meta.discourse.org/u/TGP)
#### Post date: [September 3, 2019, 7:56pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/3 "2019-09-03T19:56:35Z")

</div>

Thank you, Simon. I’ll be sure to read those topics first/next. Appreciate it.

---

<div class="post-metadata">

### Author: ![TGP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgp/32/153649_2.png) [@TGP](https://meta.discourse.org/u/TGP)
#### Post date: [September 4, 2019, 11:44pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/4 "2019-09-04T23:44:45Z")

</div>

Those threads were helpful. I’ve got [WP Discourse](https://github.com/discourse/wp-discourse) installed and connected to Discourse. I might even have some new (better) ideas for our onboarding experience. Thank you, @simon!

I stopped short of making any SSO decisions, though. Afraid the more I read about these, the more my brain goes in circles and I get dizzy. Could I trouble you for a bit more advice on this front?

Given: WordPress & MemberPress + Discourse + LearnDash… _and wanting to pay gate everything that isn’t a blog post…_

If Discourse is SSO CLIENT, we’d use MemberPress to manage accounts in WordPress and access to LearnDash courses. This was how we approached things from the start, so it inherently makes sense, if not from a place of implementation/scalability best practices.

If Discourse is SSO PROVIDER, we’d need to source and implement a paygate on the Discourse side (none of which I’ve seen so far instill much confidence, to be honest). If we could dump MemberPress on the WP side, it might be worth the switch, but I’m not sure how this would work with wanting synced users in WP accessing LMS content at special, member-prices, while the general public was presented full retail.

Does this make sense? Tried to make this clear, but I’m getting a bit turned around.

I feel like one email to Jay would handle this, but every dollar spent on dev is a dollar we don’t have for the rest of our startup plans. (Feels more and more like we should defer to Jay.) 😉

Thanks.

---

<div class="post-metadata">

### Author: ![TGP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgp/32/153649_2.png) [@TGP](https://meta.discourse.org/u/TGP)
#### Post date: [January 7, 2020, 5:28pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/6 "2020-01-07T17:28:13Z")

</div>

**Interesting development on this stack/front. @simon curious what you think.**

- MemberPress handles membership & payments processing. Easy enough.
- MemberPress is designed to manage access to _local, WordPress content._
- MemberPress has no authority to limit access to Discourse via SSO.

What I’ve discovered is that, when someone’s credit card is declined, their _membership_ is suspended, but as they can still log into WordPress, they retain access to Discourse via SSO.

**How much trouble would it be to have the SSO plugin take membership status (from MemberPress) into consideration before allowing someone to log into Discourse?**

I feel like the way we’ve integrated things at this point is cost-effective and easy enough that, if the SSO plugin handled this, we’d be golden for the foreseeable future, but I also feel like this path also leads down big boy, custom development work.

The closer we can keep things to box-stock Discourse, the better off we’ll be, imo.

Thanks again for the advice. Sorry to interrupt, Simon. 🙂

---

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [January 7, 2020, 5:59pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/7 "2020-01-07T17:59:27Z")

</div>

> [@TGP](#):
>
> when someone’s credit card is declined, their _membership_ is suspended, but as they can still log into WordPress, they retain access to Discourse via SSO.

If you can find out how MemberPress is determining which users should be able to access protected content on WordPress, then the same data can be used to restrict SSO logins to Discourse. To do that, you will need to add a conditional statement to the two functions in the second post of this topic: [How to prevent some WP users from being able to login to Discourse](https://meta.discourse.org/t/how-to-prevent-some-wp-users-from-being-able-to-login-to-discourse/93234). The conditional statement should return `true` if the user’s account has been suspended.

What you are wanting to accomplish is doable, but you may have to get some help from a WordPress developer to figure out what goes in the conditional statement in the two functions that I linked to.

---

<div class="post-metadata">

### Author: ![TGP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgp/32/153649_2.png) [@TGP](https://meta.discourse.org/u/TGP)
#### Post date: [January 7, 2020, 7:32pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/8 "2020-01-07T19:32:55Z")

</div>

Thanks as always, Simon.

Admittedly, my brain kinda hurts now from reviewing that code, but I’ll get it done. 🙂

---

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [January 8, 2020, 1:49am UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/9 "2020-01-08T01:49:05Z")

</div>

> [@TGP](#):
>
> Admittedly, my brain kinda hurts now from reviewing that code

There may be a someone on this site who could help you if you create a topic in our #Marketplace category. I see an old marketplace topic that is similar to what you are trying to accomplish: [[HIRING] Integrate our Discourse with Memberpress for membership site](https://meta.discourse.org/t/hiring-integrate-our-discourse-with-memberpress-for-membership-site/104033).

---

<div class="post-metadata">

### Author: ![TGP](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgp/32/153649_2.png) [@TGP](https://meta.discourse.org/u/TGP)
#### Post date: [January 10, 2020, 4:06pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/10 "2020-01-10T16:06:09Z")

</div>

Thanks for the advice, Simon. I’ll check it out!

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [February 9, 2020, 4:06pm UTC](https://meta.discourse.org/t/wp-sso-lms-discourse-advice-best-practices/127502/11 "2020-02-09T16:06:19Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
