I think the cause of the exception is that your function my_wpdc_sso_client_updated_user isn’t returning the $updated_user array. That array is needed for the function that adds the wpdc_sso_client_updated_user filter to continue.
You also need to set the user’s WordPress user ID in the call to update_user_meta.
This works, but disables the Simple Local Avatars plugin’s rescaling functionality:
add_filter( 'simple_local_avatars_dynamic_resize', '__return_false' ); // prevent resizing of avatars
add_filter( 'wpdc_sso_client_updated_user', 'my_wpdc_sso_client_updated_user', 10, 2 );
function my_wpdc_sso_client_updated_user( $updated_user, $query ) {
if ( isset( $query['avatar_url'] ) ) {
$new_avatar_url = $query['avatar_url'];
$wp_user_id = $updated_user['ID'];
$avatar_data = array(
'full' => $new_avatar_url, // URL of the new avatar image
);
update_user_meta( $wp_user_id, 'simple_local_avatar', $avatar_data );
}
return $updated_user;
}
The reason for preventing the resizing of avatars is because the resizing is done with the WordPress image editor code. For it to work, the image needs to be downloaded to WordPress. Note that if you leave off the add_filter( 'simple_local_avatars_dynamic_resize', '__return_false' ) line from the code above, the Simple Local Avatars plugin will attempt to resize the images, throw a PHP warning, then use the full size image - so nothing would seem broken from a user’s point of view.
I’m somewhat unsure about combining the use of Discourse avatars with the Simple Local Avatars plugin. The issue I see is that the plugin gives users the option to upload a custom avatar on WordPress. If they do that, then log back into WordPress from Discourse, they might wonder what has happened to the avatar they uploaded. It would be more complex to develop, but it might be better to add the ability to deliberately set your Discourse avatar as your WordPress avatar on the user’s WordPress profile page.