DiscourseConnect und Zeitzone/Standort des Benutzers

[troygrady]

Hallo!

Wir fügen die Möglichkeit hinzu, dass Benutzer ihre Zeitzone in WordPress anpassen können, damit ihre eigenen Aktivitäten auf unserer Website in der lokalen Zeit angezeigt werden. Während wir dies tun, dachten wir, wir könnten diese Einstellung auch auf das Forum übertragen, damit sie nicht zweimal die gleiche Einstellung vornehmen müssen. Derzeit legen Benutzer auf Discourse ihre eigene Position und Zeitzone unter „Einstellungen/Profil“ fest, daher möchten wir dies, wenn möglich, überschreiben.

Es scheint eine DiscourseConnect-Einstellung unter „site_settings/category/login“ namens „discourse connect overrides location“ zu geben. Gilt dies nur für das Feld „Standort“ oder kümmert sich dies auch um die Zeitzone? Wenn dieses Feld angekreuzt ist, woher zieht DiscourseConnect diese Informationen in der WP-Datenbank?

D. h. Wenn wir eine ähnliche eigene Einstellung implementieren, möchten wir sicherstellen, dass wir sie an der richtigen Stelle speichern, damit sie über DiscourseConnect korrekt fließt, wenn wir die Option „Standort“ aktivieren.

Vielen Dank!

[troygrady]

Nachdem ich mich damit noch etwas beschäftigt habe, vermute ich, dass die Option „Overrides Location“ in DiscourseConnect die Zeitzoneneinstellung von WordPress nicht übernimmt und dass wir diese, wenn wir sie wollen, am besten über die API festlegen, sobald der Benutzer diese Informationen bearbeitet. Lassen Sie mich wissen, ob das korrekt ist.

Ich bin mir jedoch immer noch nicht sicher, woher „location“ auf der WP-Seite kommt oder ob es überhaupt übertragen wird. Ich sehe zum Beispiel keinen „location“-Token in der „last payload“ für meinen Benutzer. Aber ich sehe Avatar, Bio, Benutzername, externe ID und so weiter. Insbesondere wird Bio übertragen, obwohl wir „override bio“ nicht aktiviert haben, also sollte „location“ vermutlich auch übertragen werden?

Wenn Sie eine Sekunde Zeit haben, @simon, glaube ich, dass Sie der Plugin-Zauberer sind. Lassen Sie mich wissen, ob Sie Einblicke haben. Danke!

[angus (Angus McLeod)]

Hallo @troygrady, Entschuldigung für die langsame Antwort (ich beantworte Fragen zum WP Discourse-Plugin). Ich werde die Zeitzonen- und Standort-Einstellungen separat behandeln (sie sind nicht miteinander verbunden).

Zeitzone

@troygrady

Wir fügen die Möglichkeit hinzu, dass Benutzer ihre Zeitzone in Wordpress anpassen können, damit ihre eigenen Aktivitäten auf unserer Website in der lokalen Zeit angezeigt werden.

Könnten Sie bitte klarstellen, ob Sie meinen, dass die Aktivitäten der Benutzer ihnen in ihrer lokalen Zeit angezeigt werden sollen? Wenn ja, ist dies im Gegensatz zu Wordpress derzeit standardmäßig in Discourse (ohne die Verwendung von DiscourseConnect) und wird automatisch aktualisiert, wenn es nicht vom Benutzer festgelegt wurde. Ich bin zum Beispiel kürzlich von der Zeitzone Australia/Perth zu Europe/Oslo gewechselt. Ich habe die Zeitzoneneinstellung in meinem Profil hier auf Meta nicht geändert, und sie lautet jetzt

Wünschen Sie ein anderes Verhalten als dieses?

Standort

Sie können einen in einem Wordpress-Benutzerprofil festgelegten Standort mit dem Standortfeld im Profil des Benutzers in Discourse synchronisieren. Es wird nicht standardmäßig synchronisiert, da es kein Standardfeld in Wordpress gibt, das dem Standortfeld in Discourse entspricht. Sie müssen hier etwas Code hinzufügen. In der Datei functions.php Ihres Themes oder an einer anderen Stelle, an der Sie Code hinzufügen können, müssen Sie etwas wie das Folgende hinzufügen, wobei der entscheidende Teil die Verwendung des wpdc_sso_params-Filters ist.

function sync_discourse_location( $params, $user ) {
    $location = get_user_meta( $user->ID, 'user_location_meta', true );
    if ( $location  ) {
        $params['location'] = $location;
    }
    return $params;
}
add_filter( 'wpdc_sso_params', 'sync_discourse_location', 10, 2 );

Beachten Sie, dass Sie ‘user_location_meta’ durch das Benutzer-Meta-Feld ersetzen müssen, das verwendet wird, um den Standort des Benutzers in Ihrer Wordpress-Instanz zu speichern (d. h. welches Feld auch immer von dem Plugin verwendet wird, das Sie verwenden, um Benutzerstandorte zu Wordpress hinzuzufügen).

Beachten Sie auch, dass das Discourse-Standortfeld nur ein “String”-Feld ist, was bedeutet, dass es einfach alles anzeigt, was buchstäblich hineingeschrieben wird. Es hat keinen Einfluss auf die Zeitzone des Benutzers und ist keine Geolokalisierung (d. h. in keiner Weise mit Kartierung verbunden).

[troygrady]

Danke Angus! Und keine Sorge wegen der Verzögerung.

@angus

@troygrady

Wir fügen die Möglichkeit hinzu, dass Benutzer ihre Zeitzone in WordPress anpassen können, damit ihre eigenen Aktivitäten auf unserer Website in der lokalen Zeit angezeigt werden.

Könnten Sie bitte klarstellen, ob Sie meinen, dass die Aktivitäten der Benutzer ihnen in ihrer lokalen Zeit angezeigt werden sollen? Wenn ja, ist dies im Gegensatz zu WordPress derzeit der Standard in Discourse.

Entschuldigung für die Verwirrung! Ja, lokale Zeitzone, und ja, das Standardverhalten von Discourse ist großartig. Wie Sie richtig bemerken, ist nicht Discourse das Problem, sondern WP, das keine Möglichkeit bietet, Benutzern die Website in ihrer lokalen Zeitzone anzuzeigen. Das wollen wir hinzufügen. Wenn wir dem Benutzer erlauben, seine Zeitzone festzulegen, dann sollten wir meiner Meinung nach auch diese Einstellung den Wert von Discourse überschreiben lassen, damit sie synchron sind. Das wollte ich wissen, ob DiscourseConnect das bietet. Es scheint nicht so zu sein.

Was ich nicht wusste, ist, dass die Discourse-Einstellung automatisch ist. Wenn das der Fall ist, werden wir es vielleicht so belassen, wie es ist. D.h. lokale Zeitzone in WP implementieren und diesen Wert nicht den Wert von Discourse überschreiben lassen. Ja, sie könnten aus dem Takt geraten, aber das ist für die meisten Benutzer vielleicht kein wirkliches Problem.

@angus

Sie können einen in einem WordPress-Benutzerprofil festgelegten Standort mit dem Standortfeld im Benutzerprofil auf Discourse synchronisieren. Es wird nicht standardmäßig synchronisiert, da es kein Standardfeld in WordPress gibt, das dem Standortfeld in Discourse entspricht.

Perfekt, das ist das fehlende Informationsstück – ich wusste nicht, woher DiscourseConnect die Standortdaten auf der WP-Seite beziehen sollte. Wir haben unser eigenes Standortfeld manuell in usermeta implementiert, sodass wir den Wert einfach über den wpdc_sso_params-Hook daraus abrufen können.

Ich bin schwerfällig, also habe ich es wahrscheinlich übersehen. Gibt es irgendwo eine Dokumentation für wpdc_sso_params? Ich habe diesen Thread gefunden, der ihn vorerst abzudecken scheint:

Map custom User Fields

You can update User Fields that you have created on Discourse via SSO. This does not require a plugin. To do this, you need to know the name that Discourse uses in the database for the custom field. The easiest way I know of to do this is by going to your Admin / Customize / User Fields page and then loading the JSON version of the page. For example https://forum.example.com/admin/customize/user_fields.json The JSON data of the page will look something like this: { user_fields: [ { id: 12, nam…

[angus (Angus McLeod)]

@troygrady

Wenn wir dem Benutzer erlauben, seine Zeitzone festzulegen, dann dachte ich, wir sollten auch diese Einstellung die Einstellung von Discourse überschreiben lassen, damit sie synchron sind. Das wollte ich wissen, ob DiscourseConnect das bietet. Es scheint, dass es das nicht tut.

Nein, Sie können Zeitzonen nicht über DiscourseConnect festlegen, und ich würde auch davon abraten, dies zu versuchen, da die plattform- und standardübergreifende Portabilität von Zeitzonen ein Minenfeld ist (es gibt mehrere “Standardlisten” von Zeitzonen mit geringfügigen Unterschieden).

@troygrady

Ich bin schwer von Begriff, also habe ich es wahrscheinlich übersehen. Gibt es irgendwo eine Dokumentation für wpdc_sso_params? Ich habe diesen Thread gefunden, der ihn vorerst abzudecken scheint:

Nicht in einem strukturierten Sinne. Ich bin dabei, die gesamte WP Discourse-Dokumentation zu überarbeiten und werde eine umfassende Liste von Aktionen und Filtern veröffentlichen

[troygrady]

Keine Ursache, kein Problem.

Zum Thema wpdc_sso_params möchten wir einen Link zur Homepage der Plattform des Benutzers einfügen und diese auf seiner Karte anzeigen. Es sieht so aus, als ob ich das als benutzerdefiniertes Feld einrichten und dann über einen ähnlichen Hook übergeben kann. Aber ich möchte, dass dies nur für unseren internen Gebrauch bestimmt ist, d. h. ich möchte nicht, dass es als etwas angezeigt wird, das der Benutzer bearbeiten kann. Da wir alle Anmeldungen auf WordPress kontrollieren und das Forenkonto automatisch verwaltet wird, würde das dieses Problem möglicherweise lösen? D. h. Wir erstellen das benutzerdefinierte Feld, legen es nach der Erstellung als nicht editierbar fest und aktualisieren es dann nur noch über SSO. Der Benutzer würde niemals eine Bearbeitungsbox irgendwo sehen?

[angus (Angus McLeod)]

Damit ich das richtig verstehe, möchten Sie Folgendes tun:

1. Ein benutzerdefiniertes Feld in WP, das die „Homepage der Plattform des Benutzers“ enthält.
2. Übergeben Sie das benutzerdefinierte Feld an Discourse über den Filter wpdc_sso_params wie hier beschrieben.
3. Zeigen Sie das benutzerdefinierte Discourse-Feld auf der Benutzerkarte an und erlauben Sie dem Benutzer nicht, es in seinem Discourse-Profil zu bearbeiten (lassen Sie „Nach der Registrierung bearbeitbar“ deaktiviert).

Wenn das richtig ist, sollte das funktionieren, vorausgesetzt, Sie haben keine Bearbeitungsfelder für das benutzerdefinierte WP-Feld in WordPress selbst.

Beachten Sie, dass Mitarbeiter Benutzerfelder (d. h. benutzerdefinierte Felder) immer bearbeiten können, auch wenn Sie „Nach der Registrierung bearbeitbar“ nicht auswählen. Um dies in Aktion zu sehen, müssen Sie es mit einem Nicht-Mitarbeiterkonto testen.

[troygrady]

Ja, das ist genau das, was wir tun wollen.

Der Haken ist, dass benutzerdefinierte Benutzerfelder auf dem Discourse-Registrierungsformular immer als editierbar angezeigt werden, selbst wenn Sie niemals beabsichtigen, dass Benutzer darauf zugreifen. Wir möchten niemals, dass Benutzer ihre Plattform-Homepage-URL bearbeiten, da diese vom System automatisch generiert wird. Da unsere Benutzer jedoch niemals ein Discourse-Registrierungsformular sehen, ist dies möglicherweise irrelevant.

Anders ausgedrückt: Gibt es eine Möglichkeit, benutzerdefinierte Felder zu erstellen, die nur für den internen Gebrauch bestimmt sind, d. h. die niemals auf einem benutzereditierbaren Formular in Discourse angezeigt werden? Ich stelle mir vor, dass es dafür viele potenzielle Verwendungsmöglichkeiten gibt, um WP- oder andere externe Plattformdaten in Discourse-Anzeigen zu integrieren.

[angus (Angus McLeod)]

@troygrady

Dies ist jedoch irrelevant, da unsere Benutzer niemals ein Discourse-Anmeldeformular sehen.

Richtig. Sie werden das Anmeldeformular nicht sehen.

@troygrady

Anders ausgedrückt: Gibt es eine Möglichkeit, benutzerdefinierte Felder zu erstellen, die nur für den internen Gebrauch bestimmt sind, d. h. die niemals auf einem benutzerbearbeitbaren Formular in Discourse erscheinen? Ich stelle mir vor, dass es viele potenzielle Anwendungen dafür gibt, um WP- oder andere externe Plattformdaten in Discourse-Anzeigen zu integrieren.

Ja, aber sie werden nicht automatisch auf der Benutzerkarte angezeigt, wo die Daten angezeigt werden sollen, oder? Trotzdem können Sie, wenn Sie das möchten, jedes beliebige Feld im wpdc_sso_params-Filter hinzufügen, z. B.

$sso_params["custom.not_a_user_field"] = "field value";

Dies wird in Discourse in der Datenbanktabelle user_custom_fields gespeichert, ist aber nirgendwo sichtbar. Sie können es mit dem Data Explorer Plugin abfragen.

[troygrady]

Okay, wir möchten beliebige Felder auf der Benutzerkarte anzeigen, die von WP generiert werden und sich auf das Konto des Benutzers auf der Hauptseite beziehen – wie die URL seiner Homepage und möglicherweise auch andere Felder. Sie sind nicht dazu bestimmt, jemals vom Benutzer eingegeben zu werden, auch nicht während der Kontoerstellung. Sie sind nur zur Anzeige für den Benutzer bestimmt. In unserem Fall scheint ein benutzerdefiniertes „Benutzer“-Feld der beste Ansatz zu sein, da es bereits Anzeigeoptionen für Profil und Karte enthält. Und der Benutzer sieht sowieso nie ein Anmeldeformular.

Der Sonderfall wäre, wenn Sie kein SSO verwenden würden – der Benutzer würde diese Felder im Anmeldeformular sehen, obwohl sie nicht dazu bestimmt sind, sie auszufüllen. Ich nehme an, die Umgehungslösung wäre, sie einfach per CSS auszublenden?

Wie auch immer, in unserem Fall scheinen wir hier unsere Lösung(en) zu haben. Danke!