WP Discourse SSO não sincroniza avatares locais fornecidos pelo Advanced Site Enhancements

[miednr]

Olá,

Estou usando:

• WordPress
• WP Discourse (última versão)
• Advanced Site Enhancements (ASE), usando seu recurso Local User Avatar (sem Gravatar)

O avatar é exibido corretamente em todo o WordPress.

O ASE armazena o ID do anexo no campo de metadados do usuário:

local_user_avatar_attachment_id

No entanto, durante o login SSO do WordPress, o Discourse sempre importa o avatar padrão em vez do avatar local.

Já tentei usar o filtro wpdc_sso_avatar_url para retornar a URL da biblioteca de mídia, mas isso não fez diferença.

Portanto, tenho duas perguntas:

1. O WP Discourse ainda usa wpdc_sso_avatar_url para sincronização de avatares?
2. Qual função ou filtro é atualmente responsável por determinar a URL do avatar enviada ao Discourse?

Qualquer orientação será apreciada.

[angus (Angus McLeod)]

Oi @miednr, sim, wpdc_sso_avatar_url ainda é usado para sincronização de avatares. Vamos ver se conseguimos fazer funcionar para você.

1. Você tem a opção Force Avatar Update (Forçar Atualização de Avatar) ativada nas configurações do Provedor DiscourseConnect?
2. Por favor, compartilhe a função que você está usando com wpdc_sso_avatar_url

[miednr]

Olá @angus !

Obrigado pela atenção com isso. Sim, tenho a opção “Forçar Atualização do Avatar” ativada.

Minha função no 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 );

Mudei algumas vezes para fazê-la funcionar. Mas, acho que, já tive uma versão melhor antes.

Seria ótimo se pudéssemos encontrar uma versão que funcione.

[angus (Angus McLeod)]

Você talvez tenha compartilhado o trecho de código errado? Esse código está usando o filtro get_avatar_url. Como você observou, o filtro é wpdc_sso_avatar_url.

[miednr]

Olá @angus

Eu usei uma abordagem diferente, que tentei. Desculpe. Este é o melhor trecho de código que posso compartilhar:

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

Tentei este trecho de código. O ASE armazena o ID do anexo do avatar local no campo de meta de usuário local_user_avatar_attachment_id. O ID do anexo existe e aponta para uma imagem na biblioteca de mídia. No entanto, o Discourse ainda importa o avatar padrão após o login/sincronização SSO do WordPress.

Também tentei a mesma abordagem com o tamanho de imagem thumbnail em vez de full, mas o resultado foi o mesmo.

Obrigado por dar uma olhada!

[miednr]

Olá @angus,

Recebi uma resposta do desenvolvedor do ASE (Advanced Site Enhancements) que pode ajudar a restringir as possibilidades.

Segundo eles:

* O ASE se integra às APIs padrão de avatar do WordPress:

* get_avatar (prioridade 5)

* get_avatar_url (prioridade 10)

* get_avatar_data (prioridade 10)

* Não há problemas conhecidos de compatibilidade com outros plugins no momento.

* O avatar local é armazenado na Biblioteca de Mídia, e o ID do anexo é salvo no campo de meta do usuário:

local_user_avatar_attachment_id

Eles também sugeriram recuperar manualmente a URL do avatar da seguinte forma:

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

}

Também tentei usar isso dentro do filtro wpdc_sso_avatar_url, mas o resultado foi o mesmo — o avatar padrão do Discourse continua sendo usado após o login.

Como o ASE afirma se integrar ao get_avatar_url(), eu estava me perguntando:

* O WP Discourse chama o get_avatar_url() antes ou depois de aplicar o filtro wpdc_sso_avatar_url?

* Há algo específico sobre a URL do avatar (tamanho, acessibilidade, timing, etc.) que o Discourse espera durante a sincronização do avatar?

Ficaria feliz em realizar testes adicionais ou adicionar depuração temporária, se isso ajudar.

Obrigado novamente pela sua ajuda!

[angus (Angus McLeod)]

Você tem a configuração do site discourse_connect_overrides_avatar ativada no Discourse?

[miednr]

@angus

discourse_connect_overrides_avatar

Sim, já foi ativado.

[angus (Angus McLeod)]

Ok, vamos verificar o que está nos parâmetros finais do SSO. Por favor, adicione este filtro e veja o que ele registra

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

[miednr]

O snippet é carregado em cada carregamento de página, mas wpdc_sso_params nunca é acionado durante o logout/login ou durante o fluxo de login do Discourse.

[angus (Angus McLeod)]

Se esse filtro nunca for acionado, é provável que você não tenha configurado o DiscourseConnect corretamente ou que não esteja usando o WordPress como provedor para fazer login no Discourse. Por favor, compartilhe o arquivo meta do WP Discourse > Logs.

[miednr]

Olá @angus

Claro, por favor, dê uma olhada:

### Servidor ###

WordPress - 7.0

PHP - 8.3.6

MySQL - 8.4.9

### Configurações do WP Discourse (Segredos Excluídos) ###

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

O WordPress está de fato configurado como provedor, mas, aparentemente, o código do DiscourseConnect não está sendo executado. Isso sugere que você não está realmente fazendo login usando o DiscourseConnect, ou não está carregando os snippets ou logs corretamente. Você talvez tenha algum outro método de login configurado, como OAuth? Talvez seja útil gravar exatamente o que você está fazendo para testar isso. Tente capturar as URLs na gravação e/ou ativando “Preserve Log” na aba de rede das ferramentas de desenvolvedor.

mas wpdc_sso_params nunca é acionado durante o logout/login ou durante o fluxo de login do Discourse

Além disso, por favor, compartilhe como você chegou a essa conclusão.

[miednr]

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

[miednr]

@angus

Isso me leva a crer que você não está, na verdade, fazendo login usando DiscourseConnect, ou que não está carregando os snippets ou logs corretamente.

1. Estou usando o DiscourseConnect para fazer login, por meio do login padrão do WordPress.
2. Estou usando o Gerenciador de Snippets do Advanced Site Enhancements (ASE) para adicionar meus snippets. E o seu snippet de depuração (modificado conforme descrito) conseguiu gerar algumas entradas no debug.log

[angus (Angus McLeod)]

Algo não está bem, pois não é possível fazer login usando DiscourseConnect sem que wpdc_sso_params seja acionado. Você precisa descobrir o que está acontecendo. Sem acesso direto à sua configuração, não consigo descobrir essa parte.

[miednr]

Obrigado, @angus, pelo seu esforço. Vou agora fazer o possível para investigar mais sobre este problema e informá-lo sobre as minhas descobertas.