Zwei-Wege-Synchronisierung zwischen WP Discourse-Benutzernamen und Discourse-Benutzernamen?

In letzter Zeit haben mein Team und ich an einer Funktion gearbeitet, die es ermöglicht, den Discourse-Benutzernamen eines Benutzers von WordPress aus zu bearbeiten, wenn das WP Discourse-Plugin installiert ist und unsere WordPress-Website als SSO-Anbieter für Discourse fungiert. Derzeit hatten wir einige Erfolge mit der Discourse-API, bei der wir ein benutzerdefiniertes Metafeld in WordPress haben, das bei Aktualisierung unsere Discourse-Instanz aufruft und eine PUT-Anfrage sendet, um den Benutzernamen des Benutzers zu aktualisieren (ähnlich einer hier vorgeschlagenen Lösung: How does one change a username via the API?).

Es gibt jedoch eine bestehende Option innerhalb von WP Discourse, wie hier gezeigt:

die es WordPress-Benutzern ermöglicht, ihren „Discourse-Benutzernamen“ über dieses Feld auf ihrer WordPress-Profilseite zu bearbeiten:

Dieses Feld wird jedoch nur zum Veröffentlichen von Beiträgen (von WP nach Discourse) verwendet und aktualisiert nicht tatsächlich den Discourse-Benutzernamen des Benutzers in Discourse. Es synchronisiert sich, wenn ein Benutzer seinen Benutzernamen in Discourse ändert, aber es synchronisiert sich nicht von WordPress nach Discourse, wenn er geändert wird.

Meine Frage ist, ob eine solche zweiseitige Synchronisierung irgendwann implementiert wird? Warum gibt es die Option, dass Benutzer dieses Feld ändern können, wenn es nicht von WordPress nach Discourse synchronisiert wird? Mein Team wäre auch daran interessiert, diese Funktion beizutragen, falls sie nicht bereits in Arbeit ist. Unsere Website benötigt diese Funktionalität, und wir stellen uns vor, dass sie auch für alle WP Discourse-Websites nützlich wäre. Bitte lassen Sie es mich wissen!

@angus @simon da Sie beide stark in WP Discourse involviert sind und uns bei unseren SSO-Problemen geholfen haben, denke ich, dass ich diese Frage an Sie richten sollte!

Ich habe diesen Beitrag in die Kategorie Support > WordPress verschoben, da die Kategorie Contribute > Feature für Discourse-eigene Features gedacht ist.

Das Feld „Discourse-Benutzername bearbeitbar“ im WordPress-Plugin ist möglicherweise schlecht benannt. Die Beschreibung der Einstellung muss auf jeden Fall aktualisiert werden, um klarzustellen, wofür sie gedacht ist. Wenn die Einstellung „Discourse-Benutzername bearbeitbar“ aktiviert ist, können Benutzer auf der WordPress-Seite ihren Discourse-Benutzernamen in ihrem WordPress-Profil festlegen. Ist diese Einstellung nicht aktiviert, kann nur ein Administrator auf der WordPress-Seite den Discourse-Benutzernamen des Benutzers festlegen. Der Discourse-Benutzername wird vom Plugin ausschließlich zum Veröffentlichen von Beiträgen von WordPress nach Discourse verwendet.

Wenn DiscourseConnect zwischen WordPress und Discourse verwendet wird, wird der Discourse-Benutzername des Benutzers zunächst aus seinem WordPress-Benutzernamen übernommen. Wenn die Einstellung auth_overrides_username auf der Discourse-Seite aktiviert ist, kann der Benutzername auf Discourse nur aus WordPress festgelegt werden. Ist die Einstellung auth_overrides_username auf Discourse nicht aktiviert, können Benutzer ihren Benutzernamen auf Discourse bearbeiten, wodurch die Benutzernamen zwischen den beiden Systemen nicht mehr synchron sein könnten.

Hinsichtlich des Feldes „Discourse-Benutzername“ wäre es ideal, wenn dieses Feld immer im Hintergrund basierend auf dem Discourse-Benutzernamen gesetzt würde. Ich habe mich mit dem zugehörigen Code nicht mehr lange beschäftigt, aber ich glaube, das Feld „Discourse-Benutzername“ wird automatisch ausgefüllt, wenn die WordPress-Seite als SSO-Anbieter für Discourse verwendet wird und die Option „Discourse-Benutzer beim Login erstellen oder synchronisieren“ auf dem Tab „DiscourseConnect-Provider-Optionen“ in WordPress aktiviert ist. Das Feld „Discourse-Benutzername“ wird auch automatisch festgelegt, wenn Discourse als SSO-Anbieter für WordPress verwendet wird (mit der DiscourseConnect-Client-Einstellung).

Idealerweise sollte das Feld „Discourse-Benutzername“ immer automatisch gesetzt werden, wenn WordPress der SSO-Anbieter für Discourse ist, unabhängig davon, ob die Option „Discourse-Benutzer beim Login erstellen oder synchronisieren“ auf Discourse aktiviert ist. Ich denke, für den Fall, dass DiscourseConnect zwischen den beiden Seiten nicht verwendet wird, kann nichts unternommen werden, aber @angus könnte dazu Ideen haben.

Standardmäßig erlaubt WordPress Benutzern nicht, ihre Benutzernamen zu ändern, daher hatten wir dazu nicht viele Fragen. Wenn Sie sicherstellen möchten, dass die Benutzernamen zwischen WordPress und Discourse synchron gehalten werden, aktivieren Sie die Einstellung auth_overrides_username auf Discourse. Möglicherweise möchten Sie auch die Option „Discourse-Benutzer beim Login erstellen oder synchronisieren“ auf WordPress aktivieren. Mit aktivierter Option werden Benutzer bei jedem Login auf Ihrer WordPress-Seite auf Discourse aktualisiert. Ist diese Option nicht aktiviert, werden Benutzer auf Discourse nur aktualisiert, wenn sie sich von Discourse abmelden und sich anschließend mit DiscourseConnect wieder anmelden.

Vielen Dank für die Antwort @simon und die Erklärung der bestehenden Funktion.

Unsere Website ist möglicherweise ein Sonderfall, da wir nicht möchten, dass der WordPress-Benutzername des Benutzers mit Discourse synchronisiert wird, gerade weil WordPress Benutzernamen standardmäßig nicht erlaubt, ihre Benutzernamen zu ändern. Und wir möchten kein Plugin installieren, das diese WP-Benutzernamen-Bearbeitungsfunktionalität hinzufügt, aufgrund der Instabilität, die dies verursachen könnte.

Da Benutzernamen jedoch in Discourse bearbeitbar sind, wäre es meiner Meinung nach sinnvoll, diese Funktionalität über das WP Discourse-Plugin in WordPress zu erweitern. Dieses Feld scheint der perfekte Ort dafür zu sein, aber ich verstehe, dass es mit dem WP-Benutzernamen in Konflikt geraten könnte, da dieser standardmäßig nie geändert würde. Ich gehe also davon aus, dass dies nichts ist, zu dem Sie möchten, dass wir zum Plugin beitragen?

Außerdem ist die Möglichkeit für Benutzer, ihren Benutzernamen im Forum zu bearbeiten, eine wichtige Anforderung für uns. Wir haben Discourse bereits so eingerichtet, dass dies möglich ist, aber die meisten unserer Benutzer ändern ihren Discourse-Benutzernamen nicht, da er in den Discourse-Einstellungen verborgen ist. Wir möchten ihn gut sichtbar auf ihrer Profilseite auf unserer Wordpress-Website neben ihren anderen Informationen wie Name, Avatar usw. haben.

Ein paar Fragen und einige Anmerkungen

Bei Neuanmeldungen sind sie jedoch gleich, da Sie DiscourseConnect verwenden. Ich gehe davon aus, dass Sie damit einverstanden sind und sich nur um die Synchronisierung an sich sorgen (d. h. nach der Kontoerstellung)?

Wie stellen Sie sich den Fall vor, dass ein Benutzer ein WordPress-Konto erstellt und sich noch nicht bei Discourse angemeldet hat? Es wird kein Discourse-Konto existieren. In diesem Fall wäre das Feld „Discourse-Benutzername“ nicht editierbar?

Beachten Sie, dass der Webhook „Benutzerdaten aktualisieren“ (siehe „Webhooks“ in den WP Discourse-Einstellungen) den Discourse-Benutzernamen in WordPress aktualisiert, wenn er in Discourse geändert wird. Das ist ein Teil der Zwei-Wege-Synchronisierung, die Sie sich vorstellen.

Sie möchten also speziell, dass das WP Discourse-Plugin den Discourse-Benutzernamen des Benutzers aktualisiert, wenn er sich ändert, ja?

Nun, dieses Feld wird von verschiedenen Personen für unterschiedliche Zwecke verwendet. Einige Personen möchten dieses Feld bearbeiten können, ohne den Benutzernamen des Discourse-Benutzers zu aktualisieren, der mit dem Konto verknüpft ist, das sie mit DiscourseConnect verwenden.

Es gibt jedoch eine relativ einfache Lösung. Wir könnten einfach eine Aktion irgendwo hier hier hinzufügen, damit Sie eine PUT-Anfrage an Discourse senden können, um den Benutzernamen in Discourse zu aktualisieren, d. h. so, wie Sie es jetzt tun. Ich würde nur hinzufügen, dass der einfache Weg dazu die Verwendung der abstrahierten discourse_request-Methode in den Dienstprogrammen des WP-Plugins ist, d. h.

use WPDiscourse\\Utilities\\Utilities as DiscourseUtilities;
$path = ''
$args =  array(
);
$response = DiscourseUtilities::discourse_request( $path, $args );

Durch die Verwendung sowohl des Webhooks als auch des Aktions-Callbacks hätten Sie eine Zwei-Wege-Synchronisierung auf die von Ihnen vorgesehene Weise, vorausgesetzt, Sie haben die beiden von mir aufgeworfenen Fragen berücksichtigt.

Gerne überprüfe und merge ich einen PR mit einer zusätzlichen Aktion in dieser Richtung.

Wir überschreiben dieses Verhalten tatsächlich mit dem Filter-Hook wpdc_sso_params, da unser SSO-System Firebase integriert und der WP-Benutzername jedes Benutzers standardmäßig seine Firebase UID ist. Daher ändern wir die Discourse-Standardeinstellung auf memberXXX (wobei XXX eine Zahl ist). Wir möchten diesen Standardwert irgendwann auch auf den Vornamen_Nachnamen des Benutzers ändern. Aber ja, unser Hauptanliegen ist, dass Benutzer ihren Benutzernamen einfach über ihre Profilseite auf unserer Wordpress-Website ändern können.

In diesem Fall denke ich, dass wir entweder das Feld für den Benutzernamen speichern und es synchronisieren lassen können, wenn das Konto erstellt wird (über den Filter-Hook wpdc_sso_params beim ersten SSO), oder wir könnten erzwingen, dass für jedes Mitglied ein Discourse-Konto erstellt wird, wenn es sich über die Discourse API auf unserer Wordpress-Website anmeldet. Die zweite Option wäre wahrscheinlich vorteilhafter, da wir wüssten, dass jeder ein Discourse-Konto hat und es somit weniger Sonderfälle gäbe, bei denen einige Benutzer Konten haben und andere nicht. Aber wir streben wirklich ein nahtloses Erlebnis an, daher möchten wir, dass dieser Benutzername das ist, was der Benutzer als seinen Benutzernamen für unsere gesamte Plattform betrachtet. Wir möchten, dass er immer editierbar ist, und in Zukunft werden wir ihn wahrscheinlich für mehr als nur Discourse verwenden (d. h. in Ranglisten usw.).

Ja, das ist genau das, was wir brauchen!

Verstanden! Vielen Dank für diese Richtung. Mein Team und ich werden dies zuerst mit unserer Implementierung testen und sollten bald einen PR erstellen!