WP Discourse SSO non sincronizza gli avatar locali forniti da Advanced Site Enhancements

[miednr]

Ciao,

Sto utilizzando:

• WordPress
• WP Discourse (ultima versione)
• Advanced Site Enhancements (ASE), utilizzando la sua funzione Local User Avatar (nessun Gravatar)

L’avatar è visualizzato correttamente ovunque in WordPress.

ASE memorizza l’ID dell’allegato nel campo meta utente:

local_user_avatar_attachment_id

Tuttavia, durante l’accesso SSO di WordPress, Discourse importa sempre l’avatar predefinito invece dell’avatar locale.

Ho già provato a utilizzare il filtro wpdc_sso_avatar_url per restituire l’URL della libreria media, ma non ha fatto alcuna differenza.

Pertanto ho due domande:

1. WP Discourse utilizza ancora wpdc_sso_avatar_url per la sincronizzazione degli avatar?
2. Quale funzione o filtro è attualmente responsabile della determinazione dell’URL dell’avatar inviato a Discourse?

Qualsiasi indicazione sarebbe apprezzata.

[angus (Angus McLeod)]

Ciao @miednr, sì, wpdc_sso_avatar_url è ancora utilizzata per la sincronizzazione degli avatar. Vediamo se riusciamo a farla funzionare per te.

1. Hai abilitato l’opzione Force Avatar Update nelle impostazioni del provider DiscourseConnect?
2. Condividi la funzione che stai utilizzando con wpdc_sso_avatar_url

[miednr]

Ciao @angus!

Grazie per aver dedicato attenzione a questo. Sì, ho “Forza Aggiornamento Avatar” abilitato.

La mia funzione in questo momento è:

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

L’ho modificata diverse volte per farla funzionare. Ma, immagino, avevo una versione migliore prima.

Sarebbe fantastico se potessimo trovare una versione funzionante.

[angus (Angus McLeod)]

Hai forse condiviso lo snippet sbagliato? Quel codice utilizza il filtro get_avatar_url. Come hai notato, il filtro è wpdc_sso_avatar_url.

[miednr]

Ciao @angus

Ho condiviso un approccio diverso che ho provato. Mi dispiace. Questo è il miglior snippet che posso condividere:

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

Ho provato questo snippet. ASE memorizza l’ID dell’immagine avatar locale nel campo meta utente local_user_avatar_attachment_id. L’ID dell’immagine esiste e punta a un’immagine nella libreria media. Tuttavia, Discourse importa comunque l’avatar predefinito dopo il login WordPress/sincronizzazione SSO.

Ho anche provato lo stesso approccio con la dimensione dell’immagine thumbnail invece di full, ma il risultato è stato lo stesso.

Grazie per aver dato un’occhiata!

[miednr]

Ciao @angus,

Ho ricevuto una risposta dallo sviluppatore di ASE (Advanced Site Enhancements) che potrebbe aiutare a restringere il campo.

Secondo quanto riportato:

• ASE si aggancia alle API standard degli avatar di WordPress:

• get_avatar (priorità 5)

• get_avatar_url (priorità 10)

• get_avatar_data (priorità 10)

• Al momento non sono noti problemi di compatibilità con altri plugin.

• L’avatar locale è archiviato nella Libreria Media e l’ID dell’allegato viene salvato nel campo meta utente:

local_user_avatar_attachment_id

Hanno anche suggerito di recuperare manualmente l’URL dell’avatar in questo modo:

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

}

Ho anche provato a utilizzare questo codice all’interno del filtro wpdc_sso_avatar_url, ma il risultato non è cambiato: dopo il login viene ancora utilizzato l’avatar predefinito di Discourse.

Poiché ASE afferma di agganciarsi a get_avatar_url(), mi chiedevo:

• WP Discourse chiama get_avatar_url() prima o dopo aver applicato il filtro wpdc_sso_avatar_url?

• Esiste qualche particolare requisito relativo all’URL dell’avatar (dimensione, accessibilità, tempistica, ecc.) che Discourse si aspetta durante la sincronizzazione degli avatar?

Sarò lieto di eseguire ulteriori test o aggiungere debug temporaneo se ciò può essere utile.

Grazie ancora per il tuo aiuto!

[angus (Angus McLeod)]

Hai abilitato l’impostazione di sito discourse_connect_overrides_avatar in Discourse?

[miednr]

@angus

discourse_connect_overrides_avatar

Sì, è stato attivato.

[angus (Angus McLeod)]

Ok, controlliamo cosa c’è nei parametri finali di SSO. Aggiungi questo filtro e controlla cosa registra

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

[miednr]

Lo snippet viene caricato a ogni caricamento della pagina, ma wpdc_sso_params non viene mai attivato durante il logout/accesso o durante il flusso di accesso di Discourse.

[angus (Angus McLeod)]

Se quel filtro non viene mai attivato, è probabile che non abbia configurato correttamente DiscourseConnect o che non stia utilizzando WordPress come provider per l’accesso a Discourse. Condivide il file meta da WP Discourse > Log.

[miednr]

Ciao @angus

certo, dai un’occhiata:

### Server ###

WordPress - 7.0

PHP - 8.3.6

MySQL - 8.4.9

### Impostazioni WP Discourse (Segreti Esclusi) ###

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

[angus (Angus McLeod)]

WordPress è effettivamente configurato come provider, ma, apparentemente, il codice DiscourseConnect non viene eseguito. Questo mi fa pensare che tu non stia effettivamente accedendo tramite DiscourseConnect, o che tu non stia caricando correttamente gli snippet o i log. Forse hai configurato qualche altro metodo di accesso, come OAuth? Prova a registrare esattamente cosa stai facendo per testare questa funzionalità. Cerca di catturare gli URL nella registrazione e/o abilitando “Preserve Log” nella scheda Network degli strumenti di sviluppo.

ma wpdc_sso_params non viene mai eseguito durante il logout/login o durante il flusso di accesso di Discourse

Inoltre, condividi come sei arrivato a questa conclusione.

[miednr]

Ho aggiunto "error_log( '\[WPDC avatar debug\] snippet loaded' );"

[miednr]

@angus

Questo mi fa pensare che tu non stia effettivamente effettuando l’accesso tramite DiscourseConnect, oppure che tu non stia caricando correttamente gli snippet o i log.

1. Sto utilizzando DiscourseConnect per l’accesso, tramite il normale login di WordPress.
2. Sto utilizzando il gestore di snippet Advanced Site Enhancements (ASE) per aggiungere i miei snippet. E il tuo snippet di debug (modificato come descritto) è riuscito a far apparire alcune voci nel debug.log

[angus (Angus McLeod)]

Qualcosa non va, poiché non è possibile effettuare l’accesso tramite DiscourseConnect senza che wpdc_sso_params venga attivato. Dovrai capire qual è il problema. Senza accesso diretto alla tua configurazione, non posso individuare quella parte.

[miednr]

Grazie @angus per il tuo impegno. Ora farò del mio meglio per approfondire questa questione e ti terrò aggiornato sui risultati.