WP Discourse SSO synchronisiert keine lokalen Avatare von Advanced Site Enhancements

Unterstützung WordPress
1

Hallo,

ich nutze:

  • WordPress
  • WP Discourse (neueste Version)
  • Advanced Site Enhancements (ASE), wobei ich die Funktion „Lokaler Benutzer-Avatar“ verwende (kein Gravatar)

Der Avatar wird in WordPress überall korrekt angezeigt.

ASE speichert die Attachments-ID im Benutzer-Meta-Feld:

local_user_avatar_attachment_id

Beim WordPress-SSO-Login importiert Discourse jedoch immer den Standard-Avatar anstelle des lokalen Avatars.

Ich habe bereits versucht, den Filter wpdc_sso_avatar_url zu verwenden, um die URL aus der Medienbibliothek zurückzugeben, aber das hat keinen Unterschied gemacht.

Daher habe ich zwei Fragen:

  1. Verwendet WP Discourse den Filter wpdc_sso_avatar_url noch für die Avatar-Synchronisierung?
  2. Welche Funktion oder welcher Filter ist derzeit dafür verantwortlich, die an Discourse gesendete Avatar-URL zu bestimmen?

Jede Hilfe wäre dankbar.

2

Hey @miednr, ja, wpdc_sso_avatar_url wird immer noch für die Avatar-Synchronisierung verwendet. Mal sehen, ob wir es für dich zum Laufen bringen können.

  1. Ist Force Avatar Update in den DiscourseConnect Provider-Einstellungen aktiviert?
  2. Bitte teile die Funktion, die du mit wpdc_sso_avatar_url verwendest.
3

Hallo @angus !

Vielen Dank für deine Aufmerksamkeit in dieser Angelegenheit. Ja, ich habe „Force Avatar Update“ aktiviert.

Meine Funktion sieht derzeit so aus:



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

Ich habe sie einige Male geändert, um zum Laufen zu bringen. Aber ich glaube, ich hatte vorher eine bessere Version. :wink:

Es wäre toll, wenn wir eine funktionierende Version finden könnten.

4

Hast du vielleicht den falschen Code-Schnipsel geteilt? Dieser Code verwendet den get_avatar_url-Filter. Wie du festgestellt hast, ist der Filter wpdc_sso_avatar_url.

5

Hallo @angus

Ich habe einen anderen Ansatz ausprobiert. Entschuldigung. Dies ist der beste Code-Schnipsel, den ich teilen kann:

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

Ich habe diesen Code-Schnipsel ausprobiert. ASE speichert die lokale Avatar-Anlage-ID im Benutzer-Meta-Feld local_user_avatar_attachment_id. Die Anlage-ID existiert und verweist auf ein Bild in der Medienbibliothek. Dennoch importiert Discourse nach dem WordPress-Login/SSO-Sync weiterhin den Standard-Avatar.

Ich habe auch den gleichen Ansatz mit der Bildgröße thumbnail anstelle von full ausprobiert, aber das Ergebnis war dasselbe.

Danke, dass du dir das ansiehst!

6

Hi @angus,

ich habe eine Antwort vom ASE (Advanced Site Enhancements)-Entwickler erhalten, die uns vielleicht weiterhelfen kann.

Laut dessen:

  • ASE nutzt die Standard-WordPress-Avatar-APIs:

  • get_avatar (Priorität 5)

  • get_avatar_url (Priorität 10)

  • get_avatar_data (Priorität 10)

  • Es sind derzeit keine Kompatibilitätsprobleme mit anderen Plugins bekannt.

  • Der lokale Avatar wird in der Medienbibliothek gespeichert, und die Attachments-ID wird im Benutzer-Meta-Feld gespeichert:

local_user_avatar_attachment_id

Sie haben auch vorgeschlagen, die Avatar-URL manuell wie folgt abzurufen:

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

}

Ich habe auch versucht, dies innerhalb des wpdc_sso_avatar_url-Filters zu verwenden, aber das Ergebnis blieb unverändert – nach dem Login wird weiterhin der Standard-Discourse-Avatar verwendet.

Da ASE behauptet, in get_avatar_url() zu haken, habe ich mich gefragt:

  • Ruft WP Discourse get_avatar_url() vor oder nach der Anwendung des wpdc_sso_avatar_url-Filters auf?

  • Gibt es etwas Spezifisches bezüglich der Avatar-URL (Größe, Zugänglichkeit, Timing usw.), das Discourse während der Avatar-Synchronisierung erwartet?

Ich würde gerne weitere Tests durchführen oder temporäres Debugging hinzufügen, wenn das helfen würde.

Nochmals danke für deine Hilfe!

7

Haben Sie die discourse_connect_overrides_avatar-Site-Einstellung in Discourse aktiviert?

8

Ja, es wurde aktiviert.

9

Ok, lass uns prüfen, was in den finalen SSO-Parametern steckt. Bitte füge diesen Filter hinzu und schau, was er protokolliert

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

Der Snippet wird bei jedem Seitenaufbau geladen, aber wpdc_sso_params wird weder beim Abmelden/Anmelden noch während des Discourse-Anmeldevorgangs ausgeführt.

11

Wenn dieser Filter nicht ausgelöst wird, liegt es wahrscheinlich daran, dass DiscourseConnect nicht korrekt eingerichtet ist oder dass du WordPress nicht als Provider für die Anmeldung bei Discourse verwendest. Bitte teile die Metadaten-Datei aus WP Discourse > Logs.

12

Hallo @angus

klar, bitte sieh dir das an:

### Server ###

WordPress - 7.0

PHP - 8.3.6

MySQL - 8.4.9

### WP Discourse Einstellungen (Geheimnisse ausgeschlossen) ###

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 ist tatsächlich als Anbieter eingerichtet, aber anscheinend wird der DiscourseConnect-Code nicht ausgeführt. Das lässt mich vermuten, dass du dich nicht tatsächlich über DiscourseConnect anmeldest oder die Snippets bzw. Logs nicht korrekt lädst. Hast du vielleicht eine andere Anmeldemethode eingerichtet, wie zum Beispiel OAuth? Versuche genau aufzuzeichnen, was du beim Testen machst. Versuche, die URLs in der Aufzeichnung zu erfassen und/oder aktiviere „Protokoll beibehalten“ im Network-Tab der Entwicklertools.

aber wpdc_sso_params wird beim Abmelden/Anmelden oder während des Discourse-Anmeldevorgangs nie ausgelöst

Bitte teile auch mit, wie du zu dieser Schlussfolgerung gekommen bist.

14

Ich habe "error_log( '\[WPDC avatar debug\] snippet loaded' );" hinzugefügt.

15
  1. Ich melde mich über DiscourseConnect an, und zwar über den standardmäßigen WordPress-Login.
  2. Ich verwende den Snippet-Manager von Advanced Site Enhancements (ASE), um meine Snippets hinzuzufügen. Und dein Debug-Snippet (wie beschrieben angepasst) hat es ermöglicht, dass Einträge in der debug.log erscheinen.
16

Etwas stimmt hier nicht ganz, denn ohne dass wpdc_sso_params ausgelöst wird, ist eine Anmeldung über DiscourseConnect nicht möglich. Du musst herausfinden, was da schiefgeht. Ohne direkten Zugriff auf deine Einrichtung kann ich das nicht klären.

17

Vielen Dank @angus für deine Bemühungen. Ich werde nun mein Bestes tun, um mehr über dieses Problem zu erfahren, und dich über meine Erkenntnisse informieren.