Synchronisation bidirectionnelle entre le nom d'utilisateur WP Discourse et le nom d'utilisateur Discourse ?utilisateur Discourse ?

Récemment, mon équipe et moi avons travaillé sur une fonctionnalité qui permet de modifier le nom d’utilisateur Discourse d’un utilisateur depuis Wordpress avec le plugin WP Discourse installé et notre site Wordpress configuré comme fournisseur SSO pour Discourse. Actuellement, nous avons eu un certain succès en utilisant l’API Discourse, où nous avons un champ méta personnalisé dans Wordpress qui, lorsqu’il est mis à jour, appelle notre instance Discourse du site avec une requête PUT pour mettre à jour le nom d’utilisateur de l’utilisateur (similaire à une solution proposée ici : How does one change a username via the API?)

Cependant, il existe une option existante dans WP Discourse comme le montre ceci :

qui permet aux utilisateurs Wordpress de modifier leur « nom d’utilisateur Discourse » via ce champ dans leur page de profil Wordpress :

mais ce champ n’est utilisé que pour publier des articles (de WP à Discourse) et ne met pas réellement à jour le nom d’utilisateur de l’utilisateur dans Discourse. Il se synchronise lorsqu’un utilisateur modifie son nom d’utilisateur dans Discourse, mais il ne se synchronise pas de Wordpress à Discourse lorsqu’il est modifié.

Ma question est, ce type de synchronisation bidirectionnelle sera-t-il implémenté à un moment donné ? Pourquoi y a-t-il une option pour permettre aux utilisateurs de modifier ce champ de nom d’utilisateur s’il ne se synchronise pas de Wordpress à Discourse ? Mon équipe serait également intéressée à contribuer à cette fonctionnalité si ce n’est pas quelque chose déjà en cours. Notre site a besoin de cette fonctionnalité, et nous imaginons qu’elle serait également utile pour tous les sites WP Discourse. S’il vous plaît, faites-moi savoir à ce sujet !

@angus @simon puisque vous êtes tous deux fortement impliqués dans WP Discourse et nous avez aidés avec nos problèmes SSO, je pense que je devrais vous adresser cette question !

J’ai déplacé ce sujet dans la catégorie Support > WordPress, car la catégorie Contribute > Feature est destinée aux fonctionnalités de Discourse.

Le champ « Discourse Username Editable » dans le plugin WordPress est peut-être mal nommé. Le texte descriptif de ce paramètre doit absolument être mis à jour pour clarifier son utilité. Lorsque le paramètre « Discourse Username Editable » est activé, les utilisateurs du site WordPress peuvent définir leur nom d’utilisateur Discourse sur leur page de profil WordPress. Si ce paramètre n’est pas activé, seul un administrateur du site WordPress peut définir le nom d’utilisateur Discourse de l’utilisateur. Le nom d’utilisateur Discourse est uniquement utilisé par le plugin pour publier des articles depuis WordPress vers Discourse.

Lorsque DiscourseConnect est utilisé entre WordPress et Discourse, le nom d’utilisateur Discourse de l’utilisateur est initialement défini à partir de son nom d’utilisateur WordPress. Si le paramètre auth_overrides_username est activé sur le site Discourse, le nom d’utilisateur sur Discourse ne peut être défini que depuis WordPress. Si le paramètre auth overrides username n’est pas activé sur Discourse, les utilisateurs pourraient modifier leur nom d’utilisateur sur Discourse, ce qui entraînerait une divergence entre les noms d’utilisateur des deux systèmes.

Concernant le champ « Discourse Username », il serait idéal que ce champ soit toujours défini en arrière-plan en fonction du nom d’utilisateur Discourse. Il y a un moment que je n’ai pas regardé le code concerné, mais je pense que le champ « Discourse Username » est rempli automatiquement si le site WordPress est utilisé comme fournisseur SSO pour Discourse et que l’option « Create or Sync Discourse Users on Login » est activée dans l’onglet des options du fournisseur DiscourseConnect sur WordPress. Le champ « Discourse Username » est également défini automatiquement si Discourse est utilisé comme fournisseur SSO pour WordPress (avec le paramètre DiscourseConnect Client).

Idéalement, le champ « Discourse Username » devrait toujours être défini automatiquement lorsque WordPress est le fournisseur SSO pour Discourse, que l’option « Create or Sync Discourse Users on Login » soit activée ou non sur Discourse. Je ne pense pas qu’il soit possible de faire quoi que ce soit dans le cas où DiscourseConnect n’est pas utilisé entre les deux sites, mais @angus pourrait avoir des idées à ce sujet.

Par défaut, WordPress n’autorise pas les utilisateurs à modifier leurs noms d’utilisateur, ce n’est donc pas un sujet qui a suscité beaucoup de questions. Si vous souhaitez vous assurer que les noms d’utilisateur restent synchronisés entre WordPress et Discourse, assurez-vous d’activer le paramètre auth_overrides_username sur Discourse. Vous souhaiterez peut-être également activer l’option « Create or Sync Discourse Users on Login » sur WordPress. Avec cette option activée, les utilisateurs seront mis à jour sur Discourse à chaque fois qu’ils se connectent à votre site WordPress. Si cette option n’est pas activée, les utilisateurs ne seront mis à jour sur Discourse que lorsqu’ils se déconnecteront de Discourse, puis se reconnecteront avec DiscourseConnect.

Merci pour votre réponse @simon et pour l’explication de la fonctionnalité existante.

Notre site pourrait être un cas un peu particulier, car nous ne souhaitons pas synchroniser le nom d’utilisateur Wordpress de l’utilisateur avec Discourse précisément parce que Wordpress ne permet pas aux utilisateurs de changer leurs noms d’utilisateur par défaut. Et nous ne voulons pas installer de plugin qui ajoute cette fonctionnalité d’édition du nom d’utilisateur WP en raison de l’instabilité qu’elle pourrait créer.

Mais comme les noms d’utilisateur sont modifiables dans Discourse, je pense qu’il serait logique d’étendre cette fonctionnalité à Wordpress via le plugin WP Discourse. Ce champ semble être l’endroit idéal pour cela, mais je comprends que cela pourrait entrer en conflit avec le nom d’utilisateur WP puisque celui-ci ne changerait jamais par défaut. Je suppose donc que ce n’est pas quelque chose que vous souhaitez que nous contribuions au plugin ?

De plus, permettre aux utilisateurs de modifier leur nom d’utilisateur sur le forum est une exigence majeure pour nous. Nous avons déjà configuré Discourse pour le permettre, mais la plupart de nos utilisateurs ne modifient pas leur nom d’utilisateur Discourse car il est caché dans les paramètres de Discourse. Nous voulons qu’il soit bien visible sur leur page de profil sur notre site Wordpress, aux côtés de leurs autres informations comme le nom, l’avatar, etc.

Quelques questions et quelques notes

Cependant, ils seront identiques lors des nouvelles inscriptions, puisque vous utilisez DiscourseConnect. Je suppose que cela ne vous pose pas de problème et que vous êtes seulement préoccupé par la synchronisation en soi (c’est-à-dire après la création du compte) ?

Comment envisagez-vous le cas où un utilisateur crée un compte Wordpress et ne s’est pas encore connecté à Discourse ? Aucun compte Discourse n’existera. Dans ce cas, le champ Nom d’utilisateur Discourse ne serait-il pas modifiable ?

Notez que le webhook « Mettre à jour les données utilisateur » (voir « Webhooks » dans les paramètres WP Discourse) mettra à jour le nom d’utilisateur Discourse dans Wordpress lorsqu’il est modifié dans Discourse. C’est une partie de la synchronisation bidirectionnelle que vous envisagez.

Donc, ce que vous recherchez spécifiquement, c’est que le plugin WP Discourse mette à jour le nom d’utilisateur Discourse de l’utilisateur lorsqu’il est modifié, n’est-ce pas ?

Maintenant, ce champ est utilisé par différentes personnes à des fins différentes. Certaines personnes veulent pouvoir modifier ce champ sans mettre à jour le nom d’utilisateur de l’utilisateur Discourse associé au compte qu’elles utilisent avec DiscourseConnect.

Cependant, il existe une solution relativement simple. Nous pourrions simplement ajouter une action quelque part ici afin que vous puissiez utiliser une requête PUT vers Discourse pour mettre à jour le nom d’utilisateur sur Discourse, c’est-à-dire comme vous le faites maintenant. J’ajouterais simplement que le moyen le plus simple de le faire est d’utiliser la méthode abstraite discourse_request dans les Utilitaires du plugin WP, c’est-à-dire :

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

En utilisant à la fois le webhook et le rappel d’action, vous auriez une synchronisation bidirectionnelle de la manière que vous envisagez, en supposant que vous ayez pris en compte les deux questions que j’ai soulevées ci-dessus.

Je serais heureux d’examiner et de fusionner une PR avec une action supplémentaire dans ce sens.

Nous remplaçons en fait ce comportement avec le hook de filtre wpdc_sso_params car notre système SSO intègre Firebase et le nom d’utilisateur WP de chacun est par défaut son UID Firebase, nous changeons donc le défaut de Discourse pour qu’il soit memberXXX (avec XXX étant un nombre). Nous voulons en fait changer ce défaut pour qu’il soit Prénom_Nom de l’utilisateur à un moment donné également. Mais oui, notre principale préoccupation est que les utilisateurs puissent facilement changer leur nom d’utilisateur via leur page de profil sur notre site Wordpress.

Dans ce cas, je pense que nous pouvons soit stocker le champ nom d’utilisateur et le faire synchroniser lors de la création du compte (via le hook de filtre wpdc_sso_params lors du premier SSO), soit forcer la création d’un compte Discourse pour chaque membre lorsqu’il s’inscrit sur notre site Wordpress via l’API Discourse. La deuxième option serait probablement plus avantageuse car nous saurions que tout le monde a un compte Discourse et il y aurait donc moins de cas particuliers où certains utilisateurs ont des comptes et d’autres non. Mais nous visons une expérience transparente, nous voulons donc que ce nom d’utilisateur soit ce que l’utilisateur considère comme son nom d’utilisateur pour l’ensemble de notre plateforme. Nous voulons qu’il soit toujours modifiable, et à l’avenir, nous l’utiliserons probablement pour plus que simplement Discourse (c’est-à-dire dans les classements, etc.).

Oui, c’est exactement ce dont nous avons besoin !

Compris ! Merci pour cette orientation, mon équipe et moi allons tester cela avec notre implémentation d’abord et devrions bientôt proposer une PR !