#6737 closed defect (bug) (fixed)
Avatar src attribute must not contain the "d" param if the Gravatar logo is chosen under Settings > Discussion > Default Avatar
| Reported by: | henry.wright | Owned by: | r-a-y |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.4.2 |
| Component: | Media | Version: | 2.4.0 |
| Severity: | normal | Keywords: | good-first-bug has-patch |
| Cc: |
Description
The Image Requests Gravatar article explains that the following image is shown when an email address has no matching Gravatar image:
The article goes on to say:
If you'd prefer to use your own default image (perhaps your logo, a funny face, whatever), then you can easily do so by supplying the URL to an image in the
d=ordefault=parameter.
If this particular image is chosen in Settings > Discussion > Default Avatar, the src attribute in the image HTML must not contain the d parameter, else the image won't display.
Steps to reproduce:
- Select the Gravatar logo under Settings > Discussion > Default Avatar
- View a BuddyPress member who a) doesn't have an uploaded profile photo and b) doesn't have a Gravatar
Attachments (2)
Change History (12)
#2
@
11 years ago
Not sure if the Gravatar API has a public changelog to find out? My guess is the Grav logo isn't a popular choice and in cases where it was chosen, a profile photo upload most probably took precedence so the problem wasn't noticed.
#4
@
11 years ago
- Keywords has-patch added; needs-patch removed
Hi r-a-y,
I was thinking the fix could be to supply the d param conditionally, only when the default Grav isn't gravatar_default (see attached patch).
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Wow, weird that we never noticed this before. Is it a recent change in the Gravatar API, or a regression on our part?