We’re adding in the ability for users to adjust their time zone in Wordpress so that their own activity on our site displays in the local time. While we do this, we figured we may as well have that setting also flow over to the forum, so they don’t have to make the same setting twice. Currently users on Discourse set their own location and time zone under preferences/profile, so we’d like to override that if possible.
There does appear to be a DiscourseConnect setting under “site_settings/category/login” called “discourse connect overrides location”. Is this just for the “location” field, or does this take care of time zone too? When this box is checked, where in the WP database is DiscourseConnect pulling this information from?
i.e. If we implement a similar setting of our own, we want to make sure we store it in the right place so it flows correctly via DiscourseConnect when we turn on the “location” option.
After poking around on this some more, I’m going to guess that checking the “overrides location” option in DiscourseConnect doesn’t take the time zone setting from Wordpress, and that if we want that, the best way would be to set it via the API whenever the user edits that information. Let me know if that’s correct.
However I’m still not sure where “location” is coming from on the WP side, or even if it’s coming over. I’m not seeing a “location” token in the “last payload” for my user, for example. But I am seeing avatar, bio, username, external_id, and so on. Notably, bio is coming over even though we don’t actually have “override bio” turned on, so presumably “location” should be coming over too?
If you have a second @simon, I believe you are the plugin wizard. Let me know if you have any insight. Thank you!
Hey @troygrady, sorry about the slow reply (I field questions on the WP Discourse plugin). I’ll address the timezone and location settings separately (they’re unconnected).
Timezone
Could you just clarify if you mean that you want user’s activity to display to them in their local time? If so, unlike in Wordpress, that’s currently the default in Discourse (without any use of DiscourseConnect), and will automatically update if not set by the user. For example, I recently went from the timezone Australia/Perth to Europe/Oslo. I haven’t touched the timezone setting in my profile here on meta, and it now reads
You can sync a location set in a Wordpress user profile with the location field in the user’s profile on Discourse. It doesn’t sync by default as there isn’t a standard field in Wordpress that’s equivalent to the location field in Discourse. You need to add some code in here. In your theme’s functions.php file or another spot you can add code, you need to add something like following, the key bit using the use of the wpdc_sso_params filter.
Note that you’ll need to substitute ‘user_location_meta’ with whatever user meta field is being used to store the user’s location on your Wordpress instance (i.e. whatever field is being used by the plugin you’re using to add user locations to Wordpress).
Also note that the Discourse location field is just a “string” field, which means that it will just display whatever is put into it literally. It has no affect on the user’s timezone and is not a geolocation (i.e. connected with mapping in any way).
Sorry for the confusion! Yes, local time zone, and yes, the standard Discourse behavior is great. As you’re pointing out, it’s not Discourse that’s the issue, it’s WP that doesn’t have the ability to let users see the site in their local timezone. This is what we want to add. If we let the user set their time zone, then I figured we should also have that setting override Discourse’s setting so that they’re in sync. This is what I wanted to know if DiscourseConnect provides. It sounds like it does not.
What I didn’t realize is that the Discourse setting is automatic. If that’s the case, we might just leave it the way it is. i.e. Implement local time zone in WP, and not have that value override the Discourse value. Yes, they could get out of sync, but that might not really be an issue for most users.
Perfect, this is the missing piece of information — I didn’t know where DiscourseConnect was supposed to be getting location data from on the WP side. We implemented our own location field manually, in usermeta, so we can just pull the value from there using the wpdc_sso_params hook.
I’m dense, so I probably overlooked it. Is their documentation for wpdc_sso_params anywhere? I found this thread, which seems to cover it for now:
No, you can’t set timezones via DiscourseConnect, and I’d recommend against attempting to do it too, as cross-platform/standard timezone portability is a bit of a minefield (there are multiple “standard” lists of timezones with slight differences).
Not in a structured sense. I’m in the process of overhauling all of the WP Discourse documentation and will be publishing a comprehensive list of actions and filters
On the topic of wpdc_sso_params, we’d like to include a link to the user’s platform homepage and display it on their card. It looks like I can set that up as a custom field and then pass it via a similar hook. But I want that to be for our internal use, i.e. I don’t actually want it to appear as something the user can edit. Since we control all signups on Wordpress, and the forum account is handled automatically, would that potentially solve that problem? i.e. We create the custom field, set it as non-editable after creation, and then just update date it via sso thereafter. The user would never actually see an edit box anywhere?
Have a WP custom field containing the “user’s platform homepage”
Pass the custom field to discourse using the wpdc_sso_params filter as described here.
Display the Discourse custom field on the user card and don’t allow the user to edit it in their Discourse profile (leaving “Editable after signup” unchecked)
If that’s right, that should work, assuming you don’t have any edit box for the WP custom field in Wordpress itself.
Just a note that staff can always edit user fields (i.e. custom fields), even if you don’t select “Editable after signup”. To see this in action you’ll need to test it with a non-staff account.
The catch is that it looks like custom user fields always appear as editable on the Discourse user signup form, even if you never intend for them to be accessible by users. We never want users to be editing their platform homepage url since that’s auto-generated by the system. However, since our users never actually see a Discourse signup form, this may be irrelevant.
To put this another way, is there a way to create custom fields that are only for internal use, i.e. that never appear on any kind of user-editable form in Discourse? I would imagine there are lots of potential uses for this in terms of integrating WP or other external platform data into Discourse displays.
Yes, but they won’t automatically appear on the user card, which is where you want the data displayed right? Nevertheless, if that’s what you want, you can just add any arbitrary field in the wpdc_sso_params filter, e.g.
This will be stored in Discourse in the user_custom_fields database table, but won’t be visible anywhere. You can query it using the Data Explorer Plugin.
Right, we’d like to display arbitrary fields on the user card, generated by WP, relating to the user’s account on the main site — like their homepage URL, and potentially other fields as well. They’re not intended to ever be user-supplied, even during account creation. They’re just inteded to be user-displayed. In our case it sounds like a custom “user” field is the best approach since it already includes display options for profile and card. And the user never sees a signup form anyway.
The edge case would be if you weren’t using SSO — the user would see those fields on the signup form, even though they’re not intended to fill them out. I suppose the workaround there would just be to hide them via CSS?
Anyway for our case, it sounds like we have our solution(s) here. Thank you!
