WP Discourse SSO ne synchronise pas les avatars locaux fournis par Advanced Site Enhancements

Bonjour,

J’utilise :

  • WordPress
  • WP Discourse (dernière version)
  • Advanced Site Enhancements (ASE), en utilisant sa fonctionnalité Avatar d’utilisateur local (pas de Gravatar)

L’avatar est correctement affiché partout dans WordPress.

ASE stocke l’ID de la pièce jointe dans le champ meta utilisateur :

local_user_avatar_attachment_id

Cependant, lors de la connexion SSO WordPress, Discourse importe toujours l’avatar par défaut au lieu de l’avatar local.

J’ai déjà essayé d’utiliser le filtre wpdc_sso_avatar_url pour retourner l’URL de la médiathèque, mais cela n’a rien changé.

J’ai donc deux questions :

  1. WP Discourse utilise-t-il encore wpdc_sso_avatar_url pour la synchronisation des avatars ?
  2. Quelle fonction ou quel filtre est actuellement responsable de la détermination de l’URL de l’avatar envoyée à Discourse ?

Toute orientation serait appréciée.

Salut @miednr, oui, wpdc_sso_avatar_url est toujours utilisé pour la synchronisation des avatars. Voyons si nous pouvons le faire fonctionner pour toi.

  1. As-tu activé l’option Force Avatar Update dans les paramètres du fournisseur DiscourseConnect ?
  2. Partage la fonction que tu utilises avec wpdc_sso_avatar_url

Bonjour @angus !

Merci d’avoir porté attention à cette question. Oui, j’ai bien activé « Forcer la mise à jour de l’avatar ».

Voici ma fonction à l’heure actuelle :



<?php
add_filter( 'get_avatar_url', function( $url, $id_or_email, $args ) {
    $user = false;
    if ( is_numeric( $id_or_email ) ) {
        $user = get_user_by( 'id', (int) $id_or_email );
    } elseif ( $id_or_email instanceof WP_User ) {
        $user = $id_or_email;
    }
    if ( ! $user ) {
        return $url;
    }
    $avatar_id = get_user_meta( $user->ID, 'local_user_avatar_attachment_id', true );
    if ( ! $avatar_id ) {
        return $url;
    }
    $local_avatar_url = wp_get_attachment_image_url( (int) $avatar_id, 'full' );
    return $local_avatar_url ?: $url;
}, 10, 3 );

Je l’ai modifiée à plusieurs reprises pour la faire fonctionner. Mais, je suppose, j’avais une meilleure version auparavant. :wink:

Ce serait génial si nous pouvions trouver une version qui fonctionne.

Avez-vous peut-être partagé le mauvais extrait ? Ce code utilise le filtre get_avatar_url. Comme vous l’avez remarqué, le filtre est wpdc_sso_avatar_url.

Bonjour @angus

Je me suis trompé d’approche, désolé. Voici le meilleur extrait que je peux partager :

add_filter( 'wpdc_sso_avatar_url', function( $avatar_url, $user_id ) {

$avatar_id = get_user_meta( $user_id, 'local_user_avatar_attachment_id', true );

if ( ! $avatar_id ) {
    return $avatar_url;
}

$local_avatar_url = wp_get_attachment_image_url( (int) $avatar_id, 'full' );

if ( ! $local_avatar_url ) {
    return $avatar_url;
}

return esc_url_raw( $local_avatar_url );

}, 10, 2 );

J’ai essayé cet extrait. ASE stocke l’identifiant de l’avatar local dans le champ de métadonnées utilisateur local_user_avatar_attachment_id. L’identifiant existe et pointe vers une image de la médiathèque. Cependant, Discourse importe toujours l’avatar par défaut après la connexion WordPress/synchronisation SSO.

J’ai également essayé la même approche avec la taille d’image thumbnail au lieu de full, mais le résultat était identique.

Merci d’avoir jeté un œil !

Bonjour @angus,

J’ai reçu une réponse du développeur d’ASE (Advanced Site Enhancements) qui pourrait nous aider à réduire le champ des recherches.

Selon lui :

  • ASE s’interfère avec les API standard des avatars WordPress :

  • get_avatar (priorité 5)

  • get_avatar_url (priorité 10)

  • get_avatar_data (priorité 10)

  • Il n’y a actuellement aucun problème de compatibilité connu avec d’autres extensions.

  • L’avatar local est stocké dans la médiathèque, et l’identifiant de la pièce jointe est enregistré dans le champ de métadonnées utilisateur :

local_user_avatar_attachment_id

Il a également suggéré de récupérer manuellement l’URL de l’avatar comme suit :

$attachment_id = (int) get_user_meta( $user_id, 'local_user_avatar_attachment_id', true );

if ( $attachment_id ) {

$avatar_url = wp_get_attachment_image_url( $attachment_id, array( 128, 128 ) );

}

J’ai également essayé d’utiliser ce code à l’intérieur du filtre wpdc_sso_avatar_url, mais le résultat est resté inchangé — l’avatar Discourse par défaut est toujours utilisé après la connexion.

Puisque ASE prétend s’interfacer avec get_avatar_url(), je me demandais :

  • WP Discourse appelle-t-il get_avatar_url() avant ou après l’application du filtre wpdc_sso_avatar_url ?

  • Y a-t-il quelque chose de spécifique concernant l’URL de l’avatar (taille, accessibilité, chronologie, etc.) que Discourse attend lors de la synchronisation des avatars ?

Je serais heureux d’effectuer d’autres tests ou d’ajouter un débogage temporaire si cela peut aider.

Merci encore pour votre aide !

Avez-vous activé le paramètre de site discourse_connect_overrides_avatar dans Discourse ?

Oui, il a été activé.

D’accord, vérifions ce qu’il y a dans les paramètres SSO finaux. Veuillez ajouter ce filtre et vérifier ce qu’il enregistre

add_filter( 'wpdc_sso_params', function ( $params ) {
   error_log( "avatar_url: {$params['avatar_url']} force: {$params['avatar_force_update']}" );
   return $params;
});

Le snippet est chargé à chaque chargement de page, mais wpdc_sso_params ne se déclenche jamais lors de la déconnexion/connexion ou pendant le flux de connexion de Discourse.

Si ce filtre ne se déclenche jamais, c’est probablement que vous n’avez pas correctement configuré DiscourseConnect, ou que vous n’utilisez pas WordPress comme fournisseur pour vous connecter à Discourse. Veuillez partager le fichier meta depuis WP Discourse > Logs.

Bonjour @angus

Bien sûr, veuillez jeter un coup d’œil :

### Serveur ###

WordPress - 7.0

PHP - 8.3.6

MySQL - 8.4.9

### Paramètres de WP Discourse (secrets exclus) ###

connection-logs - 0

display-subcategories - 1

allow-tags - 1

max-tags - 15

publish-as-unlisted - 0

full-post-content - 0

custom-excerpt-length - 100

add-featured-link - 1

auto-publish - 1

force-publish - 1

force-publish-max-age - 0

publish-failure-notice - 1

auto-track - 1

allowed_post_types - post

exclude_tags -

hide-discourse-name-field - 0

discourse-username-editable - 0

direct-db-publication-flags - 0

verbose-publication-logs - 0

enable-discourse-comments - 1

comment-type - display-public-comments-only

ajax-load - 1

load-comment-css - 1

discourse-new-tab - 1

hide-wordpress-comments - 1

show-existing-comments - 0

max-comments - 10

min-replies - 0

min-score - 0

min-trust-level - 0

bypass-trust-level-score - 0

only-show-moderator-liked - 0

custom-datetime-format -

cache-html - 0

clear-cached-comment-html - 0

verbose-comment-logs - 0

use-discourse-webhook - 1

use-discourse-user-webhook - 1

webhook-match-user-email - 0

verbose-webhook-logs - 0

verbose-sso-logs - 1

enable-sso - 1

auto-create-sso-user - 1

real-name-as-discourse-name - 0

force-avatar-update - 1

redirect-without-login - 0

sso-client-enabled - 0

sso-client-login-form-change - 0

sso-client-sync-by-email - 0

sso-client-disable-create-user - 0

sso-client-sync-logout - 0

logs-enabled - 1

WordPress est bien configuré comme fournisseur, mais, apparemment, le code DiscourseConnect ne s’exécute pas. Cela me suggère que vous ne vous connectez pas réellement via DiscourseConnect, ou que vous ne chargez pas correctement les extraits ou les journaux. N’auriez-vous pas une autre méthode de connexion configurée, telle qu’OAuth ? Essayez de filmer exactement ce que vous faites pour tester cela. Essayez de capturer les URL dans l’enregistrement et/ou en activant « Preserve Log » dans l’onglet Réseau des outils de développement.

mais wpdc_sso_params ne s’exécute jamais pendant la déconnexion/connexion ou pendant le flux de connexion Discourse

De plus, veuillez expliquer comment vous êtes arrivé à cette conclusion.

J’ai ajouté « error_log( ‘[WPDC avatar debug] snippet loaded’ ); ».

  1. Je m’authentifie bien avec DiscourseConnect, via la connexion WordPress standard.
  2. J’utilise le gestionnaire d’extraits Advanced Site Enhancements (ASE) pour ajouter mes extraits. Et votre extrait de débogage (modifié comme décrit) a permis de générer des entrées dans debug.log

Il y a quelque chose qui ne va pas, car il est impossible de se connecter via DiscourseConnect sans que wpdc_sso_params ne soit déclenché. Vous devez déterminer ce qui cause ce problème. Sans accès direct à votre configuration, je ne peux pas résoudre cette partie.

Merci @angus pour tes efforts. Je vais maintenant faire de mon mieux pour en savoir plus sur ce problème et je te tiendrai au courant de mes découvertes.