Bug #23766
closed
Default group and profile images on dev site
Added by Colin McDonald 2 months ago.
Updated 2 months ago.
Description
I'm noticing that newly-created groups and member/profiles aren't having their default images populated or saved on the dev site. See the attached screenshots for a group without the standard placeholder blue avatar on different screens and emails. I also recently created this account which didn't retain an image (also examples in the activity stream below):
https://cunyac.reclaimhosting.dev/members/colinmcd2/activity/
Files
- Assignee changed from Raymond Hoh to Boone Gorges
Boone, are you able to take a look at this?
On the third step of the group creation phase, the default group photo is not displayed on cdev. See Colin's second attachment.
On cdev, the group photo URL looks like this - https://s3.amazonaws.com/files.cunyac.reclaimhosting.dev/wp-content/blogs.dir/1/files/group-avatars/GROUP_ID/HASH-bpfull.jpg. And when attempting to access the URL, S3 returns a 403 Access Denied error.
On production, the group photo URL uses the random avatar and is served via Gravatar first - https://www.gravatar.com/avatar/HASH?s=150&r=g&d=https%3A%2F%2Fs3.amazonaws.com%2Ffiles.commons.gc.cuny.edu%2Fwp-content%2Fblogs.dir%2F1%2Ffiles%2Favatars%2Frandom%2F4.jpg.
That's as far as I got. Let me know if I can help debug.
This has to do with the circumstances surrounding the creation of the dev site. First, the dev site (and its S3 bucket) were used as a test location for the migration of user-uploaded content back in 2024. This means that it was populated with group avatars from the production site. Then, when I recreated the dev site's database, I ended up deleting all groups. This means that group IDs were being reused. So, during testing, a new group would be created with an ID like 1234, and if the old (ie production) data had a group avatar for 1234, then it was throwing off the whole avatar-loading routine. (BP correctly saw that the avatar existed, but wouldn't load it for some reasons that aren't relevant here.) I'm currently running a script that deletes all these orphaned avatars on the dev site, so that future groups created on the site won't experience the problem.
Once the routine is complete (it'll take a few hours), I'll do something similar for user avatars, where we may experience some similar reusing-old-avatars behavior.
- Status changed from New to Resolved
The group routine is complete, and now it's running for user avatars (which will take much longer still). I'll close this ticket out, but please feel free to reopen if this doesn't solve the problem after continued testing.
Also available in: Atom
PDF
