# WP Discourse 1.3.0 Release

**URL:** https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049
**Category:** Extras
**Created:** [2017 年3 月 14 日 04:19 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049 "2017-03-14T04:19:19Z")
**Posts on this page:** 20
**Page:** 1

<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: [2017 年3 月 14 日 04:19 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/1 "2017-03-14T04:19:19Z")

</div>

The latest release of the [WP Discourse](https://github.com/discourse/wp-discourse) plugin (1.3.0) is available on the [WordPress plugin repository](https://en-ca.wordpress.org/plugins/wp-discourse/) or from [GitHub](https://github.com/discourse/wp-discourse).

It fixes a few issues and adds a few features to the plugin:

- fixes the issue with avatars on Discourse being overridden by the default WordPress avatars when WordPress is used as the SSO provider.

- adds the option to sync existing users by email address when Discourse is used as the SSO provider for WordPress.

- adds configurable text options for the ‘Login with Discourse’, and ‘Link your account to Discourse’ text when Discourse is used as the SSO provider for Discourse.

- adds a notice to the new-post screen when a user hasn’t set their Discourse username.

- allows syncing logout from Discourse with WordPress when Discourse is used as the SSO provider. To make this work, add a URL in the form of `http://yoursite.com/?request=logout` to the ‘logout redirect’ setting on Discourse.

- restores the warning that is displayed when the plugin is installed on php \< 5.4.0. This is a hard thing to test. If anyone has a server with php \< 5.4.0 installed on it and wants to give it a try, it would be greatly appreciated.

- adds an action hook after a user is created when using Discourse as the SSO provider. This can be hooked into to send a ‘welcome’ email to new users who are created on WordPress through SSO. I wouldn’t recommend sending the ‘new\_user\_notification’ email here, but if you wanted to, it can be done in the theme’s `functions.php` file with some code like this:

```plaintext
add_action( 'wpdc_sso_client_after_create_user', 'testeleven_send_new_user_notification' );
function testeleven_send_new_user_notification( $user_id ) {
    wp_send_new_user_notifications( $user_id );
}

```

If these changes cause any issues, please let me know.

* * *

### Support [WP Discourse](https://github.com/discourse/wp-discourse) on OpenCollective

> **[WP Discourse - Open Collective](https://opencollective.com/wp-discourse)**
>
> Maintenance and Development of the WP Discourse WordPress plugin.

OpenCollective is like Patreon for open source projects. If your site relies on this plugin, please consider becoming a “backer” or a “sponsor” to support ongoing feature development, maintenance and support of the plugin.

![OpenCollective](https://global.discourse-cdn.com/meta/original/3X/3/d/3d4abf73c00d0a3ccda0fae5722fbdc220181e56.svg) ![OpenCollective](https://global.discourse-cdn.com/meta/original/3X/4/e/4e8241b14573332f03496385a9b78bda0d0f7779.svg)

#### Backers

[[Become a backer](https://opencollective.com/wp-discourse#backer)]

[![](https://global.discourse-cdn.com/meta/original/3X/a/6/a685cb46e2821da9065f1d320d72444e68809261.svg)](https://opencollective.com/wp-discourse/backer/0/website)  
[![](https://global.discourse-cdn.com/meta/original/3X/a/6/a685cb46e2821da9065f1d320d72444e68809261.svg)](https://opencollective.com/wp-discourse/backer/1/website)  
[![](https://global.discourse-cdn.com/meta/original/3X/a/6/a685cb46e2821da9065f1d320d72444e68809261.svg)](https://opencollective.com/wp-discourse/backer/2/website)

#### Sponsors

[[Become a sponsor](https://opencollective.com/wp-discourse#sponsor)]

[![](https://global.discourse-cdn.com/meta/original/3X/d/2/d2b16807e8df958e1a8b0431c0b58e567452d1b7.svg)](https://opencollective.com/wp-discourse/sponsor/0/website)  
[![](https://global.discourse-cdn.com/meta/original/3X/a/4/a414dad31fbadffcfb93595e4e48022795992068.svg)](https://opencollective.com/wp-discourse/sponsor/1/website)  
[![](https://global.discourse-cdn.com/meta/original/3X/f/a/fa334df4583e3682398d7a85415bae0a60d40be3.svg)](https://opencollective.com/wp-discourse/sponsor/2/website)

---

<div class="post-metadata">

### Author: ![erlend\_sh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/erlend_sh/32/119475_2.png) [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [2017 年3 月 14 日 18:33 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/2 "2017-03-14T18:33:39Z")

</div>

I took the liberty of adding in a clear mention of OpenCollective in your announcement 😉

**To the 600+ users of this plugin, please consider becoming a backer of [WP Discourse](https://github.com/discourse/wp-discourse).** Simon is doing a stellar job supporting this plugin 💯

Even $2 from the hobbyist users would go a long way. That’s a monthly coffee bought with pure ❤

---

<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: [2017 年3 月 24 日 23:21 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/3 "2017-03-24T23:21:50Z")

</div>

[WP Discourse](https://github.com/discourse/wp-discourse) 1.3.3 is now in the WordPress plugin repository. It makes a few changes. The biggest one is that it’s now possible to automatically create and login Discourse users when using WordPress as the SSO provider.

It also:

- moves the SSO Provider and SSO Client options into separate sub-tabs
- adds some inline documentation to the plugin’s options pages
- removes the connect status check from all options pages except the ‘Connection’ options tab (to make the switching tabs a little snappier)
- makes a few code changes to improve the plugin’s efficiency

To use the auto-create user option, you need to select the [Discourse SSO](https://meta.discourse.org/t/13045?silent=true) setting ‘enable all return paths.’ If you want to use this option and you have previously added an `iframe` to your site to auto-login users, you should remove that code before enabling the option.

The auto-create user option lets you set two possible return paths to WordPress after the user is created/logged-in on Discourse:

- ‘Redirect After Discourse Login’ - defaults to your site’s `home_url`
- ‘New User Redirect’ - a redirect that is used once, when a Discourse user is first created (useful for a welcome page)

From the user’s point of view, the redirects should be seamless - they just log the user into Discourse and then send them back to WordPress.

If these changes cause any issues, please let me know.

If any of the inline documentation isn’t clear, suggestions for improvements would be welcome.

 ![](https://global.discourse-cdn.com/meta/original/3X/f/9/f9d798169a8ca2449159494e31c221e212b2e294.png)

---

<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: [2017 年5 月 29 日 06:09 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/4 "2017-05-29T06:09:46Z")

</div>

[WP Discourse](https://github.com/discourse/wp-discourse) version 1.3.6 is now available in the [WordPress plugin repository](https://en-ca.wordpress.org/plugins/wp-discourse/).

The biggest change that could affect your site is that Discourse categories are now being stored as an option, instead of as a transient. If you add categories to your forum that you’d like to be available on your WordPress site, you’ll need to select the Force Category Update option on the Publishing Settings tab to fetch the new categories. For fresh installations of the plugin, or fresh updates from a previous version to version 1.3.6, the Discourse categories will be fetched automatically.

 ![](https://global.discourse-cdn.com/meta/original/3X/a/1/a1631f04fef0d18948dd03b15666f904d034782a.png)

A notification has been added to the WordPress new-post/edit-post screen that will be displayed after a post is published from WordPress to Discourse to indicate whether or not the post has been published successfully.

 ![](https://global.discourse-cdn.com/meta/original/3X/8/2/82bff135b1ff322934c9307d4d0b79b03e822783.png)

 ![](https://global.discourse-cdn.com/meta/original/3X/8/a/8a9cbf79d459b4db1a1bbcc9f17e75ead2adff84.png)

An option has been added to the Publishing settings tab to send an email to a site admin if publishing a post to Discourse fails. The email gives some indication about why the post failed to publish.

 ![](https://global.discourse-cdn.com/meta/original/3X/7/6/76dcd5f59e7f75afaff0748b65d3e3d689cc8967.png)

 ![](https://global.discourse-cdn.com/meta/original/3X/3/2/32b19a3581dd01e179b9b1f3c94d290cbe5a82d6.png)

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年5 月 29 日 12:14 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/5 "2017-05-29T12:14:10Z")

</div>

I have a site where discourse ID installed in a sub directory that’s stopped working. Could this be related?

---

<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: [2017 年5 月 29 日 16:23 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/6 "2017-05-29T16:23:13Z")

</div>

> [@pfaffman](#):
>
> I have a site where discourse ID installed in a sub directory that’s stopped working. Could this be related?

It depends what you mean by ‘stopped working.’

Previous versions of the plugin are available in the WordPress plugin repo at the bottom of this page: [WP Discourse (advanced view) – WordPress plugin | WordPress.org English (Canada)](https://en-ca.wordpress.org/plugins/wp-discourse/advanced/). Could you try installing version 1.3.5 of the plugin and see if that fixes the problem?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年5 月 29 日 16:28 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/7 "2017-05-29T16:28:08Z")

</div>

Sorry. It was vague because I had no idea what the problem was.

The answer is “no.”

I think that the (completely unrelated) problem was that Apache subtly changed something in how, uh, something was parsed in config files and the site wasn’t redirecting to https and the http side wasn’t completely configured for the sub-folder install.

Again, the problems I was having are completely unrelated to this plugin.

---

<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: [2017 年6 月 7 日 23:27 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/8 "2017-06-07T23:27:59Z")

</div>

[WP Discourse](https://github.com/discourse/wp-discourse) version 1.3.7 is now available in the [WordPress plugin repository](https://en-ca.wordpress.org/plugins/wp-discourse/).

It’s a minor update. It adds a couple of options to the SSO Provider settings.

 ![](https://global.discourse-cdn.com/meta/original/3X/f/d/fd7ceb54628842d665caef41879f39191b8177df.png)

It also adds a filter to the function that is used for syncing comment numbers between Discourse and WordPress.

> <https://github.com/discourse/wp-discourse/blob/main/lib/discourse-comment.php#L224>

The reason for this filter is that syncing comment numbers between Discourse and WordPress on archive-type pages (pages that are displaying links to multiple posts that have been published to Discourse) is very inefficient. To get around this, a longer sync period (24 hours, adjustable with the ‘discourse\_archive\_page\_sync\_period’ filter) has been set for posts displayed on archive pages than is used for posts displayed on single pages. The problem with this is that many sites use regular pages, as opposed to archive pages, to display their post archives.

Here’s an example that will set the comment numbers for all single posts and posts displayed on the home page to be synced every 10 minutes. All other comment numbers will be synced once every 24 hours.

```php
add_filter( 'wpdc_single_page_comment_number_sync', 'my_namespace_single_page_sync', 10, 2 );
function my_namespace_single_page_sync( $single_page, $post_id ) {
    // If a post archive is being displayed on a regular Page on the site's homepage
    // and you would like the comment numbers to be synced at the default 10 minute interval.
    if ( is_front_page() ) {

        return true;
    }

    // Otherwise, only single posts will be synced at the 10 minute interval, regular post
    // archives and archives being displayed on Pages will be synced once every 24 hours.
    return is_single( $post_id );
}

```

**Note** : the simplest and most efficient fix for this problem is to not display comment numbers on archive-type pages.

Todo:

- add a filter to the sync-period for single posts
- add an option to sync comment numbers with a Discourse webhook

---

<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: [2017 年6 月 14 日 00:23 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/9 "2017-06-14T00:23:42Z")

</div>

I’ve just updated the plugin to version 1.3.85. It’s a minor update, the biggest change will affect some sites that are using WordPress as the SSO Provider and are registering users with front-end registration forms. It will definitely affect sites with this setup that are using the **MemberPress plugin**.

There was a conflict between the wp-discourse email verification and MemberPress so that users were not being forced to verify their email address when they first logged into Discourse. This has been fixed.

If this affects your site, what it means is that new users will no longer be able to log into Discourse without first going through the Discourse email verification process. Also, the SSO ‘Create Discourse User on Login’ feature will not work on your site.

If you are ok with new users having to verify their email address on Discourse, and not having the ‘Create Discourse User on Login’ functionality, you don’t need to make any changes.

If you are comfortable the your users email addresses are valid (for example, if you are requiring a credit card transaction before users can sign up for a membership) you can undo the changes made by this update by inserting some code into your theme’s `functions.php` file. (Change the prefix `my_namespace_` to something unique to your site.)

This will remove the need for users to go through the Discourse email verification process:

```php
add_filter( 'discourse_email_verification', 'my_namespace_discourse_email_verification' );
function my_namespace_discourse_email_verification() {
    return false;
}

```

This will allow the ‘Create Discourse User on Login’ feature to work with email addresses that haven’t been verified by the plugin. **Do not add this function without adding the previous function.** If you enable auto\_login without bypassing the Discourse email verification, new users will have a strange experience when they first log into your site.

```php
add_filter( 'wpdc_auto_create_login_email_verification', 'my_namespace_auto_login_email_verification' );
function my_namespace_auto_login_email_verification() {
    return true;
}

```

This release also updates the settings descriptions for Publishing Username and Create Discourse User on Login. Thanks @tnorthcutt.

Edit: I wouldn’t recommend using the above code unless you are certain that the email is valid. The filters allow you to check the user\_id. They are both found in this file: [https://github.com/discourse/wp-discourse/blob/master/lib/discourse-sso.php](https://github.com/discourse/wp-discourse/blob/master/lib/discourse-sso.php). Get in touch with me if you have any questions about this.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年6 月 14 日 18:59 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/10 "2017-06-14T18:59:10Z")

</div>

Hey, @simon. There is a [discussion over at FeverBee](https://experts.feverbee.com/t/is-it-possible-for-the-feverbee-blog-posts-to-be-pulled-in-full/6192/6?u=jay_pfaffman) about the plugin and what the canonical link should be. It’s mostly SEO stuff that I don’t pretend to understand, but it seems that it might be good if the plugin could include a link that says that the WordPress site is the canonical link (or maybe have an option to choose).

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年7 月 21 日 08:42 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/11 "2017-07-21T08:42:16Z")

</div>

I spent a couple hours wondering why accounts weren’t getting created before noticing this post. Is there a reason that this needs to be done external to the plugin?

There’s no indication in the settings that “automatically create and login users” doesn’t actually work without adding this code to a theme’s `functions.php`; if there’s a reason not to let the plugin include this code, please add a link to this page or similar.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年7 月 21 日 12:13 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/12 "2017-07-21T12:13:08Z")

</div>

Hey, @simon. When I add the email verification code, it keeps PaidMembershipPro from adding a user to a membership category. Any idea why that might be? It doesn’t make any sense to me, but I mostly know nothing about WordPress development.

I’m asking on their forums as well. Thanks for any insight.

---

<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: [2017 年7 月 21 日 14:51 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/13 "2017-07-21T14:51:41Z")

</div>

> [@pfaffman](#):
>
> There’s no indication in the settings that “automatically create and login users” doesn’t actually work without adding this code to a theme’s functions.php

It works if the email address has been verified by the [WP Discourse](https://github.com/discourse/wp-discourse) plugin. The problem is that if you’re using an alternate login system to the default WordPress one, the user’s email address has to be verified by Discourse before they can login. If a user with an unverified email address is automatically logged into Discourse, it creates a strange user experience.

I think this feature needs to be reworked a bit. I’ll take a look at it.

> [@pfaffman](#):
>
> When I add the email verification code, it keeps PaidMembershipPro from adding a user to a membership category.

If you mean the code that I posted above, I don’t see how that could be happening. Possibly there’s a conflict with the Auto Login feature though. Does it work if you turn it off?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年7 月 21 日 17:35 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/14 "2017-07-21T17:35:43Z")

</div>

> [@simon](#):
>
> If you mean the code that I posted above, I don’t see how that could be happening.

Yeah. Me neither

> [@simon](#):
>
> Possibly there’s a conflict with the Auto Login feature though. Does it work if you turn it off?

Thanks. I’ll Give that a ty.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年7 月 28 日 22:50 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/15 "2017-07-28T22:50:59Z")

</div>

> [@simon](#):
>
> If you mean the code that I posted above, I don’t see how that could be happening. Possibly there’s a conflict with the Auto Login feature though. Does it work if you turn it off?

Right. If I turn off the Auto Login feature, Paid Memberships Pro (PMP) creates the user _with_ its membership level. If I turn on the Auto Login feature, PMP fails to assign the membership level when the user is created in WordPress.

I added a hook to wp\_login, but the first time they log in it fails to assign the user, presumably because the user doesn’t exist in Discourse until after the attempt to assign the Discourse group.

It’s chicken and eggs, it seems.

---

<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: [2017 年7 月 28 日 22:56 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/16 "2017-07-28T22:56:54Z")

</div>

> [@pfaffman](#):
>
> If I turn off the Auto Login feature, Paid Memberships Pro (PMP) creates the user with its membership level. If I turn on the Auto Login feature, PMP fails to assign the membership level when the user is created in WordPress.

That makes sense. Why do you need to auto login the user? Could an SSO login link added to the site’s menu solve your problem?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年7 月 28 日 23:03 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/17 "2017-07-28T23:03:39Z")

</div>

> [@simon](#):
>
> Could an SSO login link added to the site’s menu solve your problem?

I don’t know, but I don’t think so.

I need a way to get the user created in Discourse before WordPress does the API call that tries to add the user to a particular group. Right now, they have to log in to Discourse, log out of WordPress (which Discourse will do), and log in to WordPress again.

Or, if there were a way to somehow include the add-to-group thing to the SSO load, that would solve my problem. That would be best, but I have no idea how to do that.

---

<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: [2017 年7 月 28 日 23:22 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/18 "2017-07-28T23:22:02Z")

</div>

> [@pfaffman](#):
>
> I need a way to get the user created in Discourse before WordPress does the API call that tries to add the user to a particular group.

I do something like this with the WIshlist Member plugin by hooking into an action that is called when a user is added to a membership level. If the user doesn’t yet exist on Discourse, they are created through the API and then added to the appropriate group.

> [@pfaffman](#):
>
> Or, if there were a way to somehow include the add-to-group thing to the SSO load, that would solve my problem. That would be best, but I have no idea how to do that.

You can add parameters to the SSO payload by hooking into the `wpdc_sso_params` filter. Something like this should work.

```php
add_filter( 'wpdc_sso_params', 'my_namespace_sso_params', 10, 2 );
function my_namespace_sso_params( $params, $user ) {
    if ( ... ) { // Some condition.
        $params['add_groups'] = 'groups,to,add';
    }

    return $params;
}

```

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2017 年7 月 28 日 23:24 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/19 "2017-07-28T23:24:38Z")

</div>

So if I add that filter and pass the group\_id of the group in `$params['add_groups']` the Right Thing will happen over on the Discourse side (it’ll add the user to the group)?

That oughta do it.

---

<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: [2017 年7 月 28 日 23:26 UTC](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049/20 "2017-07-28T23:26:52Z")

</div>

> [@pfaffman](#):
>
> pass the group\_id of the group

I think it takes the group\_name, not the id.

[https://github.com/discourse/discourse/blob/master/app/models/discourse\_single\_sign\_on.rb#L109](https://github.com/discourse/discourse/blob/master/app/models/discourse_single_sign_on.rb#L109)

[Next page](https://meta.discourse.org/t/wp-discourse-1-3-0-release/59049.md?page=2)
