Gravatar Broken

[edent]

When I enable this plugin, it breaks my Gravatars on existing comments.

Rather than displaying, for example: img src="https://secure.gravatar.com/avatar/afc86e5b1da03f6624df8d4e4c46c92f?s=32&r=g"

I get: img src="http://gravatar_default"

If I disable the Semantic Linkbacks plugin, the gravatars return.

I'm running WordPress Version 5.3.2 and the latest IndieWeb plugins.

[edent]

In my discussion settings, I've tried using Gravatar and Identicons.

With this plugin installed, I end up with these entries in my wp_commentmeta table.

Here's what I think is happening.

I've a user with an email hash of 76d1168d9fe59976ba08622f85ad4296

check_gravatar() on https://github.com/pfefferle/wordpress-semantic-linkbacks/blob/master/includes/class-linkbacks-avatar-handler.php#L79 is constructs the URL with

$url      = 'https://www.gravatar.com/avatar/' . $hash . '?d=404';

So it receives a 404 when it checks https://www.gravatar.com/avatar/76d1168d9fe59976ba08622f85ad4296?d=404 - because the user hasn't set up a Gravatar. See documentation at https://en.gravatar.com/site/implement/images/#default-image

This returns false

So, because anonymous_avatar_data() receives false on https://github.com/pfefferle/wordpress-semantic-linkbacks/blob/master/includes/class-linkbacks-avatar-handler.php#L98

if ( self::check_gravatar( $id_or_email ) ) {
    update_comment_meta( $id_or_email->comment_ID, 'avatar', $args['url'] );
} else {
    update_comment_meta( $id_or_email->comment_ID, 'avatar', self::get_default_avatar() );
    $args['url'] = self::get_default_avatar();
}

It calls its own get_default_avatar()

public static function get_default_avatar( $type = null ) {
    if ( ! $type ) {
        $type = get_option( 'avatar_default', 'mystery' );
    }
    switch ( $type ) {
        case 'mm':
        case 'mystery':
        case 'mysteryman':
            return plugin_dir_url( dirname( __FILE__ ) ) . 'img/mm.jpg';
    }
    return apply_filters( 'semantic_linkbacks_default_avatar', $type );
}

This then sends the $type of gravatar_default to be stored incorrectly.

Temporary Fix

Removing the ?d=404 allows the default Gravatar to be shown.

Better Fix

I think get_default_avatar needs to handle retro, monsterid, wavatar, indenticon, mystery, mm, mysteryman, blank, gravatar_default - as per https://developer.wordpress.org/reference/functions/get_avatar/

[dshanske]

The whole class you referenced is now disabled if you have webmentions installed...we put a newer version of the code there, and intend to remove this code entirely in a future version...so the bug would be in the webmention version of the code

[dshanske]

If changing the class here is working for you, then it isn't being properly disabled

[dshanske]

https://github.com/pfefferle/wordpress-semantic-linkbacks/blob/master/semantic-linkbacks.php#L39

[dshanske]

@pfefferle I think when you removed the plugin class from webmentions, you created a few issues... Semantic Linkbacks loads its classes in a hook to plugins_loaded, and webmentions now does not... I think that created a load order problem.

[dshanske]

@edent If you comment out the line I cited that loads the avatar class, does it work for you then? For new mentions? Or if you resend an old one?

[edent]

@dshanske yes! Commenting out that if statement seems to let comment avatars through properly.

Although, weirdly, the Comment Admin UI still shows src="http://identicon"

[dshanske]

@edent The issue of load order is still one. But the fix for the webmention version of this problem is in https://github.com/pfefferle/wordpress-webmention/pull/249

[dshanske]

@edent Because it was stored that way, the newer version of the code inside webmentions no longer stores that info, it merely caches it for a customizable number of hours

[jsit]

Shouldn't it be possible to use this plugin without the webmentions plugin? I'm encountering the same problem here -- $args['url'] is being set to something other than a URL, which I think shouldn't be happening.

[dshanske]

@jsit The plan is to merge the two plugins at some future point. But your bug has been logged under the webmentions plugin. Either way, are you using it to enhance pingbacks and trackbacks?