WP Discourse 1.5 Release

Version 1.5.1 of the plugin is now available in the WordPress plugin repository.

The biggest change will affect sites that have previously enabled the Create Discourse User on Login option. This option no longer logs users into Discourse when they log into WordPress. If it is selected, after logging into WordPress it runs a check to see if the user exists on Discourse. If the user doesn’t exist, a user is created through the API. If you would like to add a link to your WordPress site to allow users to login directly to Discourse, you need to create an SSO login link. Have a look at the Creating an SSO Login Link section of the WP Discourse Tips and Tricks topic to see how to do that.

If you have the Create Discourse User on Login option enabled, you should see a one-time notice telling you about this change.

Other changes include:

  • adding a warning to the SSO provider tab if the WordPress admin email doesn’t match an admin user on Discourse
  • adding some functions that can be used in themes or plugins for hooking into Discourse
    • get_discourse_user( $user_id, $match_by_email = false )
    • get_discourse_user_by_email( $email )
    • create_discourse_user( $user, $require_activation = true )
    • get_discourse_groups()
    • add_user_to_discourse_group( $user_id, $group_name, $force_update = false ) // force update fetches fresh groups data from Discourse
    • remove_user_from_discourse_group( $user_id, $group_name, $force_update = false )
    • get_discourse_stats()

These are all static functions. To call them you need to include the WPDiscourse\Utilities\Utilities namespace. For example, to get a Discourse user who has a WordPress id of 12, either by id, or by email you would call:

WPDiscourse\Utilities\Utilities::get_discourse_user( 12, true );

Later this week I will create a separate topic to document these functions and give some ideas about how they can be used with WordPress membership plugins.

Version 1.5.6

Changes to the Discourse metabox

Version 1.5.6 adds an option to link existing Discourse topics to WordPress posts. It also lets you unlink posts from Discourse. What this does is remove all the Discourse metadata that is associated with a post.

The Discourse meta-box on the post edit screen defaults to this:


After publishing a post it gives you the option to Update the topic (republish the content to Discourse) or to unlink the post from Discourse:


To link to an existing Discourse topic, copy and paste the topic’s URL into the URL input. Linking to a Discourse topic will cause that topic’s comments to be displayed beneath the post. It does not overwrite the Discourse topic’s content.


After a post has been linked to an existing topic it is in the same state as it would be if you had published it from Discourse in the first place. If you then select the Update Discourse topic checkbox, the Discourse topic content will be overwritten with the content of the WordPress post. Selecting Unlink Post from Discourse will remove all Discourse meta-data. After unlinking the post, it is possible to relink it with a different topic.


(todo: remove the question mark from the Unlink Post label.)

Changes to the Force Publish option

The Force Publish option causes all posts published on WordPress, and all post’s updated on WordPress, to be published to Discourse. What has changed for this option is that it now automatically publishes to the default Discourse category that has been set on the Publishing Options tab.


wpdc_comment_body filter

A wpdc_comment_body filter has been added that gives access to the html of each Discourse comment before it is added to the comments template. This can be used to parse the comment html.
The code where the filter is added is here: https://github.com/discourse/wp-discourse/blob/master/lib/discourse-comment-formatter.php#L121

Please let me know if you run into any issues with the latest update. As always, previous versions of the plugin are available at the bottom of this page.


What was the reason for creating this breaking change?


The old method could lock people out of their WordPress site if SSO was misconfigured.

I’m wondering what the need is to log people in to Discourse when they login to WordPress. Where I have seen it used, it’s being used so that a Discourse link can be added to the WordPress site that lets users go directly to Discourse without having to go through an additional login process. For that case, it’s better to just create an SSO login link on WordPress. If there is another use case for logging in users, I can look at it more closely.

1 Like

Maybe provide an option, though, instead of just breaking things for those that don’t have it misconfigured and are relying on that. There’s a way to help new users not get locked out and not break current functionality. WordPress is big on backwards-compatibility and not breaking things.

1 Like

For sure. I was wary about making the change, and added an admin notice to tell people about it.

Yes, but we don’t necessarily share that philosophy on the Discourse project. If the original design decision was bad to start with, it should be reversed, not cast in concrete for all future generations to suffer from …


In this case, doesn’t sound like the feature is bad but that some people are misconfiguring it – as they can do with Discourse in general, really. (The issue is even mentioned in the plugin docs where it tells people what to do if they misconfigure)

So taking it away is rather nuclear when people are using it and it can be solved with an option. Since the plugin is for WordPress users, they’re expecting things to not be broken unnecessarily.

Are you open to a PR for this? This seems like something really small to have to maintain a fork over.

No, but what I can do is add an action to the new method that you can use to override it with the old code. I can get that in the next update.

I’m open to PRs for lots of other things though.

I’m curious about what functionality you are getting out of logging users into Discourse when they login to WordPress.


We have been using this plugin with no issues until this update. Now when we use the [discourse_sso_client login] shortcode on our WP login page, it just keeps looping back to the WP login page.
All the settings are correct. I double checked to ensure we had the right keys etc…
Any help in the right direction would be great.

Nothing was changed in the SSO Client code in the most recent update. Has anything else changed on your site? Have you added or updated any plugins?

We have updated the theme but no other plugins.
We are using the WOFFICE theme (https://woffice.io/?lang=en)

Was the using WordPress as the SSO client working for you before, or have you just enabled the setting recently?

If it was working before, is there any chance you could try enabling one of the default WordPress theme’s for a few minutes to see if that’s what is causing the problem?

It was working before with the WOFFICE theme. It is working with a default theme. Thanks. I will troubleshoot the WOFFICE theme.


1 Like

Thanks! If you find what the problem is, please let us know.

It’s possible that the change is related to this entry in the Woffice changelog: ‘FIX: wp-login.php redirection to /login/’. http://hub.alka-web.com/woffice/changelog If your forum and website are public, I can take a look at it.

Thanks Simon. Checking into that today. Our wiki is private but located at http://snapcentral.netsapiens.com
I will post back if/when I find the fix.

Just a detail about the SSO Sectet Key. The text next to the field says:

A string of text (numbers, letters, and symbols) at least 10 characters long.

Turns out that anything longer than 15 will be trimmed to 15. Meanwhile, Discourse will take many more characters without complaining. I spent some minutes trying to figure out why my SSO wasn’t working. The cause was that the WordPress plugin had trimmed the key silently. Maybe edit the note specifying that the key must be 10-15 characters long?

There is an issue with how the secret key is being sanitized on WordPress, but I don’t think the problem is the length. It is currently escaping left angle brackets < and also removing any part of the key that falls between pairs of angle brackets.

thisisa<test will be converted to thisisa&lt;test without any warning, and in a way that’s not obvious to the user.

thisisa<longer>test will be converted to thisisatest.

The escaping is being used to keep the WordPress codesniffer happy, but it’s not being done correctly. I’ll fix it.


I used a randomizer and I didn’t filter brackets, so that might be it indeed. Thanks!



Ken and I work together and so we are both working on this issue as it is preventing us from rolling out the site to our customers!

Here are some things I have uncovered in trying to figure out what is happening…

  1. The underlying redirect link for login via our forum is as follows; http://snapcentral.netsapiens.com/?discourse_sso=1&redirect_to=http%3A%2F%2Fsnapcentral.netsapiens.com%2Flogin%2F. I have been looking at this for the last week and it just occurred to me today that the redirect_to portion of the URL has the ASCII codes for the characters in the link instead of the actual characters! When I changed the ASCII codes to characters using Inspect Element in Chrome; lo and behold the link indeed redirects to our forum login page!

  2. Upon deactivating the wp discourse plugin the login page displayed the underlying short code which was not added anywhere to my knowledge!

Issue #1 may be related to the entry in the changelog you referred to; in that it may now be incorrectly constructing the redirect_to URL? I am going to open a ticket with the theme developer concurrently as well. My question for you is: how/where does the redirect_to URL get generated and is there a way to hardcode it? OR Can I override the default behavior of the plugin to place the login link specifically where I want on the login page?

A confounding issue here is that the theme uses a custom login URL of /login vs /wp-login

If a login to the instance would still be helpful for you to assist us then please let me know. I have a test user ready that I can message credentials for; if needed.

Thanks for all your help