WP Discourse SSO no sincroniza los avatares locales proporcionados por Advanced Site Enhancements

Soporte WordPress
1

Hola,

Estoy utilizando:

  • WordPress
  • WP Discourse (última versión)
  • Advanced Site Enhancements (ASE), usando su función de avatar de usuario local (sin Gravatar)

El avatar se muestra correctamente en todas partes en WordPress.

ASE almacena el ID del adjunto en el campo de metadatos del usuario:

local_user_avatar_attachment_id

Sin embargo, durante el inicio de sesión SSO de WordPress, Discourse siempre importa el avatar predeterminado en lugar del avatar local.

Ya intenté usar el filtro wpdc_sso_avatar_url para devolver la URL de la biblioteca de medios, pero no hizo ninguna diferencia.

Por lo tanto, tengo dos preguntas:

  1. ¿WP Discourse sigue usando wpdc_sso_avatar_url para la sincronización de avatares?
  2. ¿Qué función o filtro es actualmente responsable de determinar la URL del avatar que se envía a Discourse?

Cualquier orientación sería apreciada.

2

Hola @miednr, sí, wpdc_sso_avatar_url sigue usándose para sincronizar los avatares. Veamos si podemos hacer que funcione para ti.

  1. ¿Tienes habilitada la opción Force Avatar Update en la configuración del proveedor de DiscourseConnect?
  2. Por favor, comparte la función que estás usando con wpdc_sso_avatar_url
3

Hola @angus !

Gracias por tu atención en esto. Sí, tengo «Forzar actualización de avatar» habilitado.

Mi función en este momento es:



<?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 );

La he cambiado algunas veces para que funcione. Pero, supongo, que antes tenía una versión mejor. :wink:

Sería genial si pudiéramos encontrar una versión que funcione.

4

¿Quizás compartiste el fragmento incorrecto? Ese código utiliza el filtro get_avatar_url. Como observaste, el filtro es wpdc_sso_avatar_url.

5

Hola @angus

Compartí un enfoque diferente que intenté. Perdón. Este es el mejor fragmento que puedo compartir:

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 );

Probé este fragmento. ASE almacena el ID del adjunto del avatar local en el campo de metadatos del usuario local_user_avatar_attachment_id. El ID del adjunto existe y apunta a una imagen de la biblioteca multimedia. Sin embargo, Discourse sigue importando el avatar predeterminado después del inicio de sesión en WordPress/sincronización SSO.

También intenté el mismo enfoque con el tamaño de imagen thumbnail en lugar de full, pero el resultado fue el mismo.

¡Gracias por echarle un vistido!

6

Hola @angus,

He recibido una respuesta del desarrollador de ASE (Advanced Site Enhancements) que podría ayudar a reducir las posibilidades.

Según ellos:

  • ASE se conecta a las APIs estándar de avatares de WordPress:

  • get_avatar (prioridad 5)

  • get_avatar_url (prioridad 10)

  • get_avatar_data (prioridad 10)

  • Actualmente no hay problemas de compatibilidad conocidos con otros plugins.

  • El avatar local se almacena en la Biblioteca de medios y el ID de adjunto se guarda en el campo de metadatos de usuario:

local_user_avatar_attachment_id

También sugirieron recuperar manualmente la URL del avatar de esta manera:

$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 ) );

}

También intenté usar esto dentro del filtro wpdc_sso_avatar_url, pero el resultado fue el mismo: sigue usándose el avatar predeterminado de Discourse después de iniciar sesión.

Dado que ASE afirma conectarse a get_avatar_url(), me preguntaba:

  • ¿WP Discourse llama a get_avatar_url() antes o después de aplicar el filtro wpdc_sso_avatar_url?

  • ¿Hay algo específico sobre la URL del avatar (tamaño, accesibilidad, momento, etc.) que Discourse espere durante la sincronización de avatares?

Estaré encantado de realizar pruebas adicionales o agregar depuración temporal si eso ayuda.

¡Gracias nuevamente por tu ayuda!

7

¿Tienes activada la configuración del sitio discourse_connect_overrides_avatar en Discourse?

8

Sí, se ha activado.

9

Vale, revisemos qué hay en los parámetros finales de SSO. Por favor, añade este filtro y comprueba qué registra

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

El fragmento se carga en cada carga de página, pero wpdc_sso_params nunca se activa durante el cierre de sesión/inicio de sesión ni durante el flujo de inicio de sesión de Discourse.

11

Si ese filtro nunca se activa, es probable que no tengas DiscourseConnect configurado correctamente o que no estés usando WordPress como proveedor para iniciar sesión en Discourse. Por favor, comparte el archivo meta desde WP Discourse > Registros.

12

Hola @angus

Claro, echa un vistazo:

### Servidor ###

WordPress - 7.0

PHP - 8.3.6

MySQL - 8.4.9

### Configuración de WP Discourse (se excluyen secretos) ###

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

13

WordPress está configurado como proveedor, pero, aparentemente, el código de DiscourseConnect no se está ejecutando. Esto me sugiere que no te estás autenticando realmente mediante DiscourseConnect, o que no estás cargando correctamente los fragmentos de código o los registros. ¿Tienes acaso configurado algún otro método de inicio de sesión, como OAuth? Graba exactamente lo que estás haciendo para probarlo. Intenta capturar las URLs en la grabación y/o habilitando «Preservar registro» en la pestaña de red de las herramientas de desarrollo.

pero wpdc_sso_params nunca se ejecuta durante el cierre de sesión/inicio de sesión ni durante el flujo de inicio de sesión de Discourse

Además, por favor comparte cómo llegaste a esta conclusión.

14

Añadí “error_log( ‘[WPDC avatar debug] snippet loaded’ );”

15
  1. Estoy usando DiscourseConnect para iniciar sesión, a través del inicio de sesión estándar de WordPress.
  2. Estoy usando el Administrador de fragmentos de Advanced Site Enhancements (ASE) para agregar mis fragmentos. Y tu fragmento de depuración (modificado como se describe) pudo permitir que hubiera algunas entradas en debug.log
16

Algo no está del todo bien, ya que no es posible iniciar sesión con DiscourseConnect sin que se ejecute wpdc_sso_params. Necesitas averiguar qué es eso. Sin acceso directo a tu configuración, no puedo resolver esa parte.

17

Gracias, @angus, por tus esfuerzos. Ahora haré lo posible por averiguar más sobre este problema y te haré saber mis hallazgos.