November 3, 2016 in Classic self-hosted technical help
This is a fix for a problem that I've come across in my community.
In some cases where you enable Gravatar, some users' default avatars appear as broken images as demonstrated in the following screenshot
That's because the users will have as default the Gravatar option assigned to them (once you activate Gravatar), even though they have no selection whatsoever in the database.
Let me explain properly.
Here are two member rows (from core_member table) [see pp_main_photo, pp_photo_type], whereas the first member uses the default avatar and it appears normally, while the second one is a member that has the default avatar appearing as a broken image.(pp_gravatar stays empty even when a gravatar is being used from the same email address as the member's account or it has the gravatar email address being used if different from the account; pp_main_photo has the path to the photo when gravatar is being used correctly)
That's because the second member doesn't have any selection whatsoever on the photo_type which is the following over at your profile.
When you don't have any selection in the database it assumes the member is using Gravatar, even if they aren't.
If they don't have an avatar photo, Gravatar uses a service (i1.wp.com) to fetch the default avatar image from your community and display it.
However, that does not work on some cases, especially if you're using certain protection measures. I've experienced HTTP 404 errors and a 0004 error which is specific to the service itself.So, how can you fix it?
You just need to run the following query to assign type "none" to all your members that have no avatar (pp_main_photo) (note that it is blank and not null).
UPDATE core_members SET pp_photo_type = 'none' WHERE pp_main_photo = '';
Default avatars are now showing correctly.
That's it! Hope it helped.
Please correct me if I wrote anything wrong along the way.
Is this fixed now? Is it safe to enable use of gravatars on the profiles?
It should work in normal scenarios, you only need to do this if you're experiencing the same issue.
This happened to me in IP.Board 3 and when I upgraded to 4 the issue persisted, so I had to fix it this way. The error on i1.wp.com might be related to the Anti-DDoS firewall service we use as I've been told by Invision's support, although I've had them disable the whole protection and the issue still persisted.
If a member uses an email that isn't registered in Gravatar on the Gravatar option the avatar still appears as nothing here.
Invision could probably make the default option "none" instead of blank to prevent this situation. I'm not an expert though, there might be other, and better, ways to fix this, someone from the staff could probably offer some insight.
This topic is now archived and is closed to further replies.
Started November 13
Started 6 hours ago
Started 5 hours ago