Trouble with wp-discourse logins

I’m helping with an instance with wp-discourse and a day or to ago (I think when they upgraded to beta6) SSO logins started to fail. They seem to be failing with

{:primary_email=>"has already been taken"}

so somehow it’s not connecting existing accounts correctly?

Verbose SSO log: Record was invalid: User 
{:primary_email=>"has already been taken"}

{"admin"=>false, "moderator"=>false, "locale"=>nil, "name"=>"Jay Pfaffamn", "title"=>nil, "username"=>"jaypfaffman1"}

SSO Diagnostics:
avatar_force_update: false
external_id: 16719
name: Jay Pfaffamn
nonce: bc8ed4--------------
require_activation: true
username: jaypfaffman

  Rendering session/sso_login.html.erb within layouts/no_ember
  Rendered session/sso_login.html.erb within layouts/no_ember (0.3ms)
  Rendered layouts/_head.html.erb (3.9ms)
  Rendered common/_discourse_stylesheet.html.erb (0.2ms)
  Rendered application/_header.html.erb (0.2ms)
Completed 500 Internal Server Error in 31ms (Views: 3.1ms | ActiveRecord: 12.5ms)

They claim that nothing has happened on the WP side lately.

Matching up by email will never happen if you have require_activation: true. I don’t think anything has changed on the Discourse side recently… the last change to that logic was 7 months ago.


Strange. Is that activation in function.php or in the wp-discourse web interface? (If the site weren’t down (to logins) I’d rtfm).

Oh, are you using Discourse as the SSO provider? Or WP as the SSO provider? (I was assuming the latter)

WP is SSO provider. . . .

My suspicion was the new security thing (that I can’t quite remember what it was now) caused the problem. They had http:// rather than https:// for the SSO_URL, even though the site was https (and I guess redirecting to https so it still worked). But that doesn’t seem to make sense either.

1 Like

Does this user exist in the database?

SingleSignOnRecord.where(external_id: 16719)

How about a user with your email?


No. I checked a couple (of the SingleSignOnRecords)and it seems that they aren’t getting created? (Users are fine and created)

I tried creating a new user, as I was concerned that it might actually be true that I’d created a user on the discourse side that was causing a problem.

Looks like the last two created was one for the site owner yesterday (probably just before he did an upgrade at the web console?) and another from a new user today. “Seen” for that user is not set (on /admin/users).

So it looks like the user is getting created, but it’s failing when it tries to create the SSO Record?

Hey, this looks strange:

{"admin"=>false, "moderator"=>false, "locale"=>nil, "name"=>"Jay Pfaffman", "title"=>nil, "username"=>"pfaffman-test21"}

username there is pfaffman-test21 but username is pfaffman-test2

Yes. And I can confirm that another user also has 1 appended to the username.

Maybe the problem is require_activation: true? WP does do email validation, so it’s safe to turn that off. Maybe they did some WP change and took out whatever was settgin require_activation: false before?

The require_activation parameter is set by the WP Discourse plugin if a site isn’t using the default WordPress registration system. When it is set, WordPress users are not matched to Discourse users by their email address. Existing users who already have an SSO record associated with them should have no problem logging in though. New users should also be able to create accounts without any problem.

Are all SSO logins failing on the site? Are you able to try creating a new account on WordPress and then logging into Discourse via SSO?

You might find some useful information here: Debugging and fixing common SSO issues.


OK. Manually creating the SignleSignOnRecord makes the login work.

It does seem clear that something changed on the WP side?

And that’s been the case for at least seven months.

I think I’ve seen that this can be overridden by adding. . . something . . . to functions.php?

I think that it’s true that no users can log in, though I don’t have very good data.

I don’t see a plugin that is obviously a non-standard WordPress registration system. Could something else be triggering that as a false-positive?

Here are some:

  • “Cimy User Manager”
  • " Eonet Manual User Approve"
  • new user approve
  • ONTRApages – ONTRApages for WordPress allows ONTRAPORT & ONTRApages Premium users to connect to their accounts and easily host their landing pages on their own WordPress sites

There haven’t been any recent changes to the WP Discourse SSO login code.

If manually creating the SSO record is fixing the issue, then the problem seems to be that the user IDs that are being sent from WordPress as the external_id don’t match the external IDs on the user’s Discourse SSO record. This can happen if a user’s account is deleted and then recreated on the WordPress site. I wouldn’t expect it to affect all users on a site though.

Another case the will cause problems when the require_activation parameter is set to true is for users who were created on Discourse prior to SSO being implemented. This would also affect users that were created on Discourse with the rake admin:create task.

If a site is using the default WordPress registration system, users will be registering through a form that looks like this:

Responding to the email that is sent after completing this registration form is what removes the require_activation flag for a user.

You can find instructions for disabling the require_activation flag in this post: How to turn off Discourse email verification?.

You should try to confirm if other users on the site are able to login via SSO. The easiest way to do that would be to create a new account on the WordPress site with an email address that you have not yet used on the Discourse site. If you are able to login with a new account, that will make it easier to figure out what’s causing the problem.


Thanks very much. I did a couple searches for require_activation and couldn’t find the “how to turn off…”.

When the sun comes up in WordPress guys side of the world hopefully they can resolve this. I don’t know whether the registration system changed recently and the site owner doesn’t seem to know either.

I presume this resolves this, I’ll report back when I know more.

Thanks again.

1 Like

I’ve avoided writing a #howto topic about this, because it’s generally a bad idea. The intention behind the discourse_email_verification filter is that it will be only used when another email verification system is in place.

There are some upcoming changes to the WP Discourse plugin that will allow WordPress admins to mark an email address as valid to handle email verification on a per-user basis. That should be good enough to deal with most cases.


That makes sense. I mostly think that even with a #howto, it’s hard enough to fuss with the code to turn off email verification that it’s unlikely that someone will do it when they shouldn’t. But I could definitely be wrong.

This system emails a plain-text password (!) both when the account is created and when you want to reset the password. While that’s a horrible idea, it does validate the email. I suppose the place to put that hook is to have it run when the person successfully logs in on the WP side.

1 Like

Hi, I’m the “WordPress guy” on this project.

I figured it’d be worthwhile to jump in here and ask whether the upcoming changes could be manually added to the current version of the WP-Discourse plugin so we can get rid of this problem?

On the WordPress side the registration process has not changed in any way since November 2017. We use the EONet Manual User Approve plugin, which allows users to register but not login, and on manual approval by an admin, the user is then made active and issued a password they can either continue to use, or change on first login.

(I would also like to point out that the normal WordPress user system is still in use, the only change made by the EONet plugin is for the initial activation. All users that register are 100% normal WordPress users.)

I have hooked into the approval process so that a user is only created in Discourse once their account is approved, so email verification should not be an issue. If there’s a way to specify that require_activation not be turned on then that sounds like the way to solve this.


Hey, @Frank_Bailey!

See How to turn off Discourse email verification? and there’s a filter to add to turn off the activation requirement.

I’m befuddled why this just started happening, as both you and @simon say that nothing has changed. And I’ve no reason not to believe either of you.

My best guess is that something happened in WordPress? Have you updated anything in the past few days?

There’ve been a chunk of WordPress updates over the past few days, but nothing that should’ve impacted anything remotely related to user registration or the Discourse link. The SSO was even working fine after we went HTTPS on the WordPress side about a month ago. There was also the forced PHP 7.2 upgrade on WPEngine a couple weeks back, but as I say there have been recent group discussions held on BFP where there were no issues with registrations or logins…

Frankly it’s a bit of a head-scratcher.

1 Like

Well, you sound like someone who knows where to stick that filter! I’m several hours in to this little project to get this far. I hope that you can stick in the code and we’re back in business. (And then maybe I’ll get you to get my site up to date with WP and WooCommerce! :wink:)

Hi Jay, I’ve put in the filter and now testing a new registration and I’ll post an update here shortly. Kind of you to think of me for your WordPress work! :slight_smile:

1 Like

Well I’m ecstatic to report that adding the filter worked to get a new user into Discourse without throwing any errors, so thanks to Simon, Jay and David for all your help on this!

For any future visitors to this thread, the filter that fixed the issue was

add_filter( 'discourse_email_verification', 'wpdc_custom_discourse_email_verification', 10, 2 );
function wpdc_custom_discourse_email_verification( $require_activation, $user_id ) {
    if (/* some condition */) {
        $require_activation = false;

    return $require_activation;
1 Like