WP-Discourse "Path to your Login Page" setting

[shaiful]

Hi there,

I am using Wordpress as the identity provider for Discourse using DiscourseConnect.

In the WP-Discourse > DiscourseConnect Provider setting, how does the Path to your Login Page field work?

I set it to my dedicated Sign In page expecting that when someone clicks the Login button in Discourse they will be redirected to the /sign-in page in WP but it’s not happening in my case. Discourse brings the user to the WP homepage with some query string for example http://wp.test/?redirect_to=/?sso=abc&sig=123&qwe=456.

Please advise.

[darkpixlz (Pyx)]

Are you sure it’s not WordPress redirecting to the /?redirect_to endpoint? It’s unlikely that Discourse is doing that..

[angus (Angus McLeod)]

Your issue here is likely connected with your local networking issue. I’d suggest focusing on that first.

WP-Discourse not connected and admin email not recognized

Hi there, I am using Wordpress as the identity provider for Discourse using DiscourseConnect. What is the meaning of these errors in the screenshot in WP-Discourse plugin? [image] You are not connected to Discourse. Check that your connection settings are correct. If the issue persists, enable connection logs and check Logs. There is no admin user on Discourse with the email address admin@xxx.xxx. If you have an existing Discourse admin account, before enabling DiscourseConnect please ens…

[shaiful]

Thanks @darkpixlz @angus for your input. I will try to fix the networking issue first.

By the way is my assumption correct for how the “Path yo your login page” field is supposed to work?

@shaiful

I set it to my dedicated Sign In page expecting that when someone clicks the Login button in Discourse they will be redirected to the /sign-in page in WP

[shaiful]

I set it to my dedicated Sign In page expecting that when someone clicks the Login button in Discourse they will be redirected to the /sign-in page in WP

I have confirmed that is indeed how the setting is supposed to work.

Anyway this issue is caused by the membership plugin we are using called Memberium that also manages user auths. We have resolved it temporarily by creating a custom WP plugin to patch redirects and URL encoding while the official plugin devs work on an official fix.

Cheers!