WP Discourse 1.3.0 Release

Plugin Extras
1

The latest release of the WP Discourse plugin (1.3.0) is available on the WordPress plugin repository or from GitHub.

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:

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 on OpenCollective

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 OpenCollective

Backers

[Become a backer]



Sponsors

[Become a sponsor]



19 Likes
2

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

To the 600+ users of this plugin, please consider becoming a backer of WP Discourse. Simon is doing a stellar job supporting this plugin :100:

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

7 Likes
3

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 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.

Screenshot 2017-03-24 16.19.31.png1084×946 158 KB

11 Likes
4

WP Discourse version 1.3.6 is now available in the WordPress plugin repository.

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.

Screenshot 2017-05-28 21.51.41.png865×328 43.8 KB

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.

Screenshot 2017-05-28 21.53.13.png1108×409 42.2 KB

Screenshot 2017-05-28 21.55.03.png1108×432 42.3 KB

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.

Screenshot 2017-05-28 21.51.14.png974×315 38.8 KB

Screenshot 2017-05-28 23.06.47.png833×486 43.3 KB

4 Likes
5

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

6

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). Could you try installing version 1.3.5 of the plugin and see if that fixes the problem?

3 Likes
7

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.

3 Likes
8

WP Discourse version 1.3.7 is now available in the WordPress plugin repository.

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

Screenshot 2017-06-07 15.36.23.png850×202 25.3 KB

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/master/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.

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
4 Likes
9

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:

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.

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. Get in touch with me if you have any questions about this.

2 Likes
10

Hey, @simon. There is a discussion over at FeverBee 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).

6 Likes
11

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.

12

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.

13

It works if the email address has been verified by the 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.

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?

1 Like
14

Yeah. Me neither

Thanks. I’ll Give that a ty.

15

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.

16

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?

17

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.

18

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.

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

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;
}
19

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.

20

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

1 Like