If you are developing this on your local computer, you can create a debug.log file in your wp-content folder, and add the following to your wp-config.php file so that you can write to the file:
This will let you add calls to write_log to your code so that you can see whatâs going on. For example, in the dcpmp_get_level_for_id function, you can add:
write_log( 'In the dcpmp_get_level_for_id function, called with the id argument set to: ', $id );
That will let you know if the function is being called, and what argument is being passed to it. Make sure that write_log calls are removed before you add the code to your live site. It is usually possible to work through code in this way, to figure out where it is going wrong.
Glad the sync is working now! Makes sense that it only applies for new / updated members â the way WordPress works, the code that syncs users to Discourse groups only fires when triggered by certain actions e.g. new member added or membership level changed.
To fill in missing data for existing members added before the syncing was configured, youâd basically want to run a simple script to get all users, loop through and check member level for each, and if applicable call the relevant Discourse group functions.
I am working with someone who wants to connect WooCommerce Subscriptions with Discourse, but has Discourse as the SSO master.
It looks like when someone places the order they might not already have a Discourse account, so hooking into the âsubscription changedâ hooks canât work.
My current notion is that it might be possible to add a hook to WordPress that gets called at a successful login to WordPress that would then push the group membership over to Discourse. Do you think that could work? Is there some better idea?
Maybe use the API to send a PM to the email address first, creating a staged user account? Iâve found the staged user functionality, probably undocumented and largely unintended, to be super handy - e.g. you can even set a staged userâs notification levels for topics and categories so they can participate by email even before they create their account.
When Discourse is used as the SSO provider, you can check if a WordPress user has a Discourse account by checking if the value returned by this statement is empty:
Youâll need to do something to handle the case where the user doesnât yet have a Discourse account. Creating the user via the API and adding them to the appropriate groups is probably the right solution. It will take some work to set that up.
Yeah. The error message is fine (I guess it should mention âsso masterâ, but I knew right away). Itâs just that it wasnât what I expected, and itâs taken me forever to figure it out. (Not your fault.)
What Iâm trying to do now is have a function called at login. Iâm trying to get the Discourse username so that I can then do an old-school curl to an API call to add to the group.
That is the correct way to get the userâs Discourse id if it has been set. $user_id needs to be the WordPress userâs ID. If youâre getting an empty response, the user has not logged in via Discourse yet. Try making the call with a user you know has logged into WordPress from Discourse.
Yeah, writing to a log file is what I wanted to do, but it seems that the only way I have access to the log on this webhost is by getting it emailed to me.
My solution is pushing stuff to https://pipedream.com/ . Itâs quite painful, but better than anything else Iâve found today. My problem before is that I need to do something different to push an array to the pipedream webhook than I do for the integer that get_user_meta returned.
Well, it seems that if I do a curl within a wp_login action, it interferes with the SSO connection. (OOps, Iâm not passing the API key, but I donât think thatâs the problem.)
Is there maybe something that gets called immediately after SSO is complete?
Maybe
wpdc_sso_client_after_login_link
edit: I think that might do it. Now to see if I can add to group via user_id rather than username. . .
nope. Need to figure out how php will let me access user_nicename out of $user = wp_get_current_user(); Itâs right there.
Well, of course, itâs $discourse_username = $user->data->user_nicename;
I donât think that php had that -> syntax when I learned it in 1997.
But now, the user_nicename changes. Sometimes itâs correct, and sometimes itâs got a -2 appended. Iâm logging out and then clicking Login via your forum account in the same browser window. This doesnât seem right.
Youâre kind of in uncharted territory with this. Itâs going to be hard to develop it on a live site. Iâm not sure whatâs going on with the nice_name, but Iâm going to take a closer look at that tomorrow.
Yeah. Thatâs on me. Setting up a staging sites with SSO seemed like itâd be a bigger problem than fighting with what was already working. It was going to be simple. This is one more reason to finish my Ansible tooling to support WordPress.
Iâm a Discourse Sysadmin, dammit, not a WordPress developer!
Thanks. Unlike pretty much every other question Iâve had in this exchange, that does seem like a . Thanks for all of your help!
Yes, this is a bug. I can only reproduce it if a username is changed on Discourse after an account is created on WordPress. Iâll get this fixed by early next week.