Nous ajoutons la possibilité pour les utilisateurs d’ajuster leur fuseau horaire dans WordPress afin que leur propre activité sur notre site s’affiche à l’heure locale. Pendant que nous faisons cela, nous avons pensé que nous pourrions aussi faire en sorte que ce paramètre s’applique au forum, afin qu’ils n’aient pas à faire le même réglage deux fois. Actuellement, les utilisateurs de Discourse définissent leur propre emplacement et fuseau horaire dans les préférences/profil, nous aimerions donc outrepasser cela si possible.
Il semble y avoir un paramètre DiscourseConnect sous « site_settings/category/login » appelé « discourse connect overrides location ». Ceci est-il uniquement pour le champ « location », ou s’occupe-t-il également du fuseau horaire ? Lorsque cette case est cochée, d’où DiscourseConnect extrait-il ces informations dans la base de données WP ?
Par exemple, si nous mettons en œuvre un paramètre similaire du nôtre, nous voulons nous assurer que nous le stockons au bon endroit afin qu’il s’écoule correctement via DiscourseConnect lorsque nous activons l’option « location ».
Après avoir examiné cela de plus près, je suppose que la sélection de l’option « remplacements de localisation » dans DiscourseConnect ne prend pas le fuseau horaire de WordPress, et que si nous le voulons, le meilleur moyen serait de le définir via l’API chaque fois que l’utilisateur modifie ces informations. Faites-moi savoir si c’est correct.
Cependant, je ne suis toujours pas sûr d’où vient la « localisation » du côté de WP, ni même si elle est transmise. Je ne vois pas de jeton « localisation » dans la « dernière charge utile » pour mon utilisateur, par exemple. Mais je vois l’avatar, la bio, le nom d’utilisateur, l’identifiant externe, etc. Notamment, la bio est transmise même si nous n’avons pas activé le « remplacement de la bio », donc on peut supposer que la « localisation » devrait également être transmise ?
Si vous avez une seconde @simon, je crois que vous êtes le magicien des plugins. Faites-moi savoir si vous avez des éclaircissements. Merci !
Salut @troygrady, désolé pour la réponse lente (je réponds aux questions sur le plugin WP Discourse). J’aborderai les paramètres de fuseau horaire et de localisation séparément (ils sont sans rapport).
Fuseau horaire
Pourriez-vous simplement clarifier si vous souhaitez que l’activité des utilisateurs s’affiche pour eux dans leur heure locale ? Si c’est le cas, contrairement à Wordpress, c’est actuellement le comportement par défaut dans Discourse (sans aucune utilisation de DiscourseConnect), et cela se mettra automatiquement à jour si l’utilisateur ne le définit pas. Par exemple, je suis récemment passé du fuseau horaire Australia/Perth à Europe/Oslo. Je n’ai pas touché au paramètre de fuseau horaire dans mon profil ici sur meta, et il indique maintenant
Voulez-vous un comportement différent de celui-ci ?
Localisation
Vous pouvez synchroniser une localisation définie dans un profil utilisateur Wordpress avec le champ de localisation dans le profil utilisateur sur Discourse. Cela ne se synchronise pas par défaut car il n’y a pas de champ standard dans Wordpress qui soit équivalent au champ de localisation dans Discourse. Vous devez ajouter du code ici. Dans le fichier functions.php de votre thème ou à un autre endroit où vous pouvez ajouter du code, vous devez ajouter quelque chose comme suit, la partie clé utilisant le filtre wpdc_sso_params.
Notez que vous devrez remplacer ‘user_location_meta’ par le champ meta utilisateur qui est utilisé pour stocker la localisation de l’utilisateur sur votre instance Wordpress (c’est-à-dire le champ utilisé par le plugin que vous utilisez pour ajouter des localisations utilisateur à Wordpress).
Notez également que le champ de localisation de Discourse est juste un champ de type “chaîne de caractères”, ce qui signifie qu’il affichera littéralement tout ce qui y est mis. Il n’a aucun effet sur le fuseau horaire de l’utilisateur et n’est pas une géolocalisation (c’est-à-dire connecté à la cartographie d’une quelconque manière).
Désolé pour la confusion ! Oui, fuseau horaire local, et oui, le comportement standard de Discourse est excellent. Comme vous le soulignez, ce n’est pas Discourse qui pose problème, c’est WP qui n’a pas la capacité de permettre aux utilisateurs de voir le site dans leur fuseau horaire local. C’est ce que nous voulons ajouter. Si nous laissons l’utilisateur définir son fuseau horaire, j’ai alors pensé que nous devrions également avoir ce paramètre qui remplace le paramètre de Discourse afin qu’ils soient synchronisés. C’est ce que je voulais savoir si DiscourseConnect le fournissait. Il semble que non.
Ce que je n’avais pas réalisé, c’est que le paramètre Discourse est automatique. Si tel est le cas, nous pourrions simplement le laisser tel quel. C’est-à-dire implémenter le fuseau horaire local dans WP, et ne pas laisser cette valeur remplacer la valeur Discourse. Oui, ils pourraient se désynchroniser, mais cela pourrait ne pas être un problème pour la plupart des utilisateurs.
Parfait, c’est la pièce d’information manquante - je ne savais pas d’où DiscourseConnect était censé obtenir les données d’emplacement du côté WP. Nous avons implémenté notre propre champ d’emplacement manuellement, dans usermeta, nous pouvons donc simplement extraire la valeur de là en utilisant le hook wpdc_sso_params.
Je suis lent, donc je l’ai probablement négligé. Y a-t-il de la documentation pour wpdc_sso_params quelque part ? J’ai trouvé ce fil, qui semble le couvrir pour l’instant :
Non, vous ne pouvez pas définir de fuseaux horaires via DiscourseConnect, et je déconseillerais d’essayer de le faire non plus, car la portabilité des fuseaux horaires multiplateformes/standards est un peu un champ de mines (il existe plusieurs listes “standards” de fuseaux horaires avec de légères différences).
Pas de manière structurée. Je suis en train de remanier toute la documentation de WP Discourse et je publierai une liste complète des actions et des filtres
Sur le sujet de wpdc_sso_params, nous aimerions inclure un lien vers la page d’accueil de la plateforme de l’utilisateur et l’afficher sur sa carte. Il semble que je puisse configurer cela comme un champ personnalisé, puis le transmettre via un hook similaire. Mais je veux que ce soit pour notre usage interne, c’est-à-dire que je ne veux pas qu’il apparaisse comme quelque chose que l’utilisateur peut modifier. Puisque nous contrôlons toutes les inscriptions sur Wordpress, et que le compte du forum est géré automatiquement, cela pourrait-il résoudre ce problème ? C’est-à-dire, nous créons le champ personnalisé, le définissons comme non modifiable après sa création, puis le mettons simplement à jour via sso par la suite. L’utilisateur ne verrait jamais de champ de modification nulle part ?
Pour que je sois clair, ce que vous voulez faire est :
Avoir un champ personnalisé WP contenant la « page d’accueil de la plateforme de l’utilisateur »
Transmettre le champ personnalisé à Discourse en utilisant le filtre wpdc_sso_params comme décrit ici.
Afficher le champ personnalisé Discourse sur la carte utilisateur et ne pas permettre à l’utilisateur de le modifier dans son profil Discourse (laisser « Modifiable après l’inscription » décoché)
Si c’est correct, cela devrait fonctionner, en supposant que vous n’ayez aucune boîte de modification pour le champ personnalisé WP dans WordPress lui-même.
Notez simplement que le personnel peut toujours modifier les champs utilisateur (c’est-à-dire les champs personnalisés), même si vous ne sélectionnez pas « Modifiable après l’inscription ». Pour voir cela en action, vous devrez tester avec un compte non-staff.
Le hic, c’est qu’il semble que les champs utilisateur personnalisés apparaissent toujours comme modifiables sur le formulaire d’inscription des utilisateurs Discourse, même si vous n’avez jamais l’intention qu’ils soient accessibles par les utilisateurs. Nous ne voulons jamais que les utilisateurs modifient l’URL de leur page d’accueil de plateforme car elle est générée automatiquement par le système. Cependant, puisque nos utilisateurs ne voient jamais de formulaire d’inscription Discourse, cela pourrait être sans importance.
Pour le dire autrement, existe-t-il un moyen de créer des champs personnalisés qui sont uniquement à usage interne, c’est-à-dire qui n’apparaissent jamais sur un formulaire modifiable par l’utilisateur dans Discourse ? J’imagine qu’il existe de nombreuses utilisations potentielles à cet égard pour intégrer des données de WP ou d’autres plateformes externes dans les affichages Discourse.
C’est exact. Ils ne verront pas le formulaire de connexion.
Oui, mais ils n’apparaîtront pas automatiquement sur la carte utilisateur, qui est l’endroit où vous souhaitez que les données soient affichées, n’est-ce pas ? Néanmoins, si c’est ce que vous voulez, vous pouvez simplement ajouter n’importe quel champ arbitraire dans le filtre wpdc_sso_params, par exemple :
Cela sera stocké dans Discourse dans la table de base de données user_custom_fields, mais ne sera visible nulle part. Vous pouvez l’interroger à l’aide du plugin Data Explorer.
Bien, nous aimerions afficher des champs arbitraires sur la carte utilisateur, générés par WP, relatifs au compte de l’utilisateur sur le site principal — comme l’URL de leur page d’accueil, et potentiellement d’autres champs également. Ils ne sont jamais destinés à être fournis par l’utilisateur, même lors de la création du compte. Ils sont juste destinés à être affichés par l’utilisateur. Dans notre cas, il semble qu’un champ personnalisé « utilisateur » soit la meilleure approche puisqu’il inclut déjà des options d’affichage pour le profil et la carte. Et l’utilisateur ne voit de toute façon jamais de formulaire d’inscription.
Le cas limite serait si vous n’utilisiez pas l’authentification unique (SSO) — l’utilisateur verrait ces champs sur le formulaire d’inscription, même s’ils ne sont pas destinés à les remplir. Je suppose que la solution de contournement serait simplement de les masquer via CSS ?
Quoi qu’il en soit, dans notre cas, il semble que nous ayons nos solutions ici. Merci !
