WP Discourse plugin installation and setup


(Simon Cossar) #21

If you don’t enable the Multisite Configuration option and don’t enable the Sync Comment Data Webhook on any of your subsites, everything should function on your sites in the same way as it did before this update.

If you don’t enable the Multisite Configuration option, you can enable the Sync Comment Data webhook individually for each subsite. You can enable it for some subsites and leave it disabled for others. You’ll need to add a webhook, using the correct Payload URL on Discourse, for each subsite that you’ve enabled. The subsite’s Payload URL is available in the Sync Comment Data Webhook setting description on each subsite. Doing this might make sense if you are publishing to different Discourse categories from each subsite, or if only one or two of your subsites were displaying Discourse comments.

It will be possible to do this after the next update. I’ve added a filter that you can hook into to exclude particular subsites from the multisite configuration. That update will be available in the next couple of days.

If you run into any issues with the plugin’s multisite functionality, please let me know.

(Mike Brown) #22


I followed the instructions exactly for setting up WordPress as the Provider for SSO.

Everything seems to work correctly but now when I log in it logs me in as a User with a different username versus logging me in an as the Admin.

I obviously need to be logged in as the Admin. Can you please tell me how to resolve this?

There is also an option in the WordPress plugin under SSO Provider which says

Should this option be selected? I ask because there is no mention of it in the instructions.

I also ask because it seems like the plugin did this by default when it created a new username for me and logged me in as a User and not an Admin.

Just to clarify… after following the instructions to setup SSO with WordPress as the Provider, the SSO worked but it logged me in as a User and not the Admin. It also seems like it automatically created a new username for me instead of using my Admin credentials.

Any help or insight you can provide will be greatly appreciated.

I look forward to your response.


(Jay Pfaffman) #23

viist /users/admin-login to log in as the admin user and add your new SSO user as admin.

Or create account on WP with your admin email address.

(Simon Cossar) #24

When a user first logs in from WordPress to Discourse, Discourse attempts to find the user by their WordPress email address. If there is no Discourse user with the email address, a new user is created. This is probably what is happening in your case.

To fix the problem, login to Discourse as your admin user by visiting /users/admin-login/ (yourforum.com/users/admin-login). You will be sent an email with a link that allows you to log in. Then go to the admin users page on Discourse. Find the user that was created when you first logged in from WordPress to Discourse. Delete that user. Then go to your preferences page and edit your Discourse email address so that it matches your WordPress email address. You should then be able to login as the admin user from WordPress to Discourse. Once you have successfully logged in from WordPress to Discourse, the users are linked through the WordPress user_id. You can change your Discourse email back to it’s previous value if you need to.

This isn’t the first time this problem has come up. I think the easiest fix is to describe the problem in the WP Discourse SSO documentation. If admin emails don’t match, changing the Discourse admin email address before SSO is enabled is easier than changing it after it has been enabled.

(Jay Pfaffman) #25

That’s true. But people won’t read that until they can’t log in as an admin. I don’t really see a solution. Maybe you could link to the /users/admin-login link in the plugin. Oh, or somehow use the API key to authorize some user as an admin.

But, really, if you figure out how to get people to read instructions before they break things you could take over the world.

(Mike Brown) #26

Hello Simon and Jay,

Thank you both so much for the information.

@Simon_Cossar - Your workflow was correct and resolved the issue but there were a few things on my end that might be “user-specific steps” (depending on how they have WordPress settings configured) that need to be taken into consideration as well.

This workflow resolved the issue but I had to revoke Admin/Moderator privileges from the User that was auto-created (MikeBrown1) before I could delete the User. So it seems the User that was auto-created was also assigned the Admin/Moderator role.

Specifically for me I also had to make sure that my WordPress Admin/Keymaster email address was the same as the email address found in General ----> Settings —> Email Address (for me they were not the same so this was causing an issue). They are now both the same.

Thanks for your support and I hope this information helps resolve similar issues in the future.

Best Regards,

(Simon Cossar) #27

When the SSO Provider option is first enabled, the plugin can check if there’s an admin user on Discourse with the current WordPress user’s email address. If not, it can print a warning message with instructions about how to fix the problem.

(Mike Brown) #28

Hey Guys,

One more question which was not addressed.

There is also an option in the WordPress plugin under SSO Provider which says (see screenshot)

Should this option be selected? I ask because there is no mention of it in the instructions.

I also ask because it seems like the plugin did this by default when it auto-created the user MikeBrown1 and logged me in as a new User and not the Admin.

If I select the option to Create Discourse User on Login what exactly will happen differently than if it is not selected?

Thanks in advance for your help on this question.

Best Regards,

(Simon Cossar) #29

No, you don’t need to select it. The reason for that setting is that people are wanting to create Discourse accounts for WordPress users before they have logged into Discourse with SSO. Your MikeBrown1 account would have been created when you logged into Discourse. With the Create Discourse User on Login setting enabled, the Discourse account would have been created automatically when you logged into WordPress, without requiring you to login to Discourse to create the account.

(Jay Pfaffman) #30

That sounds lots better than expecting someone to rtfm! I say yes!

(Mike Brown) #31

Hey @Simon_Cossar Simon,

Thanks for the follow-up.

Sorry, Simon. I’m a little confused about this.

I’ll provide you a little background so you know how I intend on using Discourse.

I’m setting Discourse up as the community forum to my membership site so it won’t be open to the public.

I’m using MemberPress to run my membership site and when someone joins they are logged as a subscriber within WordPress and MemberPress.

At this point they have access to all the protected content I’ve created (for members only) this includes the community forum (Discourse) access.

So now that I have SSO enabled what happens by default?

What I want to have happen is…

When they click the “Community” link from within the members only area it takes them to Discourse where they have the ability to configure their User Profile.

I would like them to be able to modify their Username and add a picture of their choice along with Bio information. I’m assuming their email is the only thing they would not be able to change.

So is this how it will work by default?

If I select Create Discourse User on Login would this limit their ability to modify their profile?

If there is already documentation on this subject please let me know and I’ll be happy to read that first before asking these questions.


(Simon Cossar) #32

Yes, for your case, don’t enable the Create Discourse User on Login option. Discourse users will be created when they login by clicking on the Community link from your members only area.

Go to the settings section of your Discourse forum and enter ‘sso’ in the search box. Scroll to the bottom of that page. You’ll see a list of SSO options: ‘sso overrides bio’… I think the default settings will give you what you’re looking for.

(Bhanu Sharma) #33

Any Updates on SSO Client in Wordpress Multisite?

I’m looking forward to installing the Plugin in that exact case where I need forum users to be able to log into the wordpress site.

(Simon Cossar) #34

There are two possible scenarios for this:

  • connect a single forum to multiple WordPress sites
  • connect multiple forums to multiple WordPress sites

The first scenario can be made to work. I can look at it more closely today and get back to you. The second scenario (connecting multiple forums to multiple WordPress sites) will require quite a few changes to the plugin. I don’t think it will be possible to do that in the near future.

(Bhanu Sharma) #35


I’m exactly looking at case #1 (Connecting a Single Forum to a Wordpress Network).

is there a Possibility of Introducing conditional connection such that only the users having access to certain wordpress site are able to log in?

to explain the case:

i have Wordpress Multisite set up on a domain and it uses the subdomain sites mode
I want a selected group of subsites to be able to sign in if that can be made possible.
or else, global login also works.

(Simon Cossar) #36

Not at the moment, but I think it should be possible. I’ll get back to you later today.

(Bhanu Sharma) #37

I’d be happy use my set up as a testing ground just in case.

(Simon Cossar) #38

This should take care of it. The notice is displayed when the SSO Provider tab is selected, so hopefully it catches people before the option is enabled.


I’ve error on webhooks. Comments doesnt seems on the Wordpress blog.

500 error.


Date: Tue, 21 Nov 2017 16:01:50 GMT
Content-Type: application/json; charset=UTF-8
Connection: close
Set-Cookie: __cfduid=d0474092f4a9c61b81c8; expires=Wed, 21-Nov-18 16:01:50 GMT; path=/; domain=.gameofthronestr.com; HttpOnly
Vary: Cookie
X-Robots-Tag: noindex
Link: <http://www.*********.com/wp-json/>; rel="https://api.w.org/"
X-Content-Type-Options: nosniff
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
Access-Control-Allow-Headers: Authorization, Content-Type
Allow: POST
Server: cloudflare-nginx
CF-RAY: 3c14deb286f163cd-FRA


{"code":"discourse_webhook_error","message":"Unable to process Discourse webhook.","data":null}

(Simon Cossar) #40

That error happens when the webhook’s secret key does not match the webhook secret key stored on WordPress. I need to change the error message so that it gives a better idea of what the problem is. Either a secret key has not been set on Discourse, or the secret key is set, but it doesn’t match the WordPress secret.

It is possible that you are running into a bug that is escaping a few special characters when the webhook secret key is saved on WordPress. Having ‘<’ or ’ >’ characters in the secret key will cause this problem. I will add a fix for this. To check if that is the case, could you try using a secret key that only contains alphanumeric characters?