Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.With the current implementation of user avatars, no module can support external avatars without adding custom theme code.
This patch will allow external urls to be set for user->picture but it will be up to modules to set that properly.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 187374-user-picture-external-D7.patch | 723 bytes | dave reid |
| #3 | user.module.external_0.patch | 494 bytes | halkeye |
| user.module.external.patch | 493 bytes | halkeye |
Comments
Comment #1
catchThis is a patch, and a feature request.
Comment #2
wim leersAn additional space is needed between the comma and "TRUE".
Comment #3
halkeye commentedupdated
Comment #4
Anonymous (not verified) commentedShouldn't the administrator be given an option to allow external URL for the avatar? I can see this being an issue for some.
Comment #5
catchShould definitely be an admin option since this opens up user privacy issues yeah.
Comment #6
halkeye commentedI don't see why an admin needs the option for this patch, nor any privacy issues.
All it does is allow modules to set $user->picture to a url instead of only allowing local files, there shouldn't be a way, with drupal core, to set this to a url.
Can someone show me where I'm wrong about this?
Comment #7
Anonymous (not verified) commentedI don't know what you're trying to say. User.module is a Drupal core module. Allowing external links for the avatar should be a choice that I (as administrator) need to make. External links could cause issues with the page display. Even if I allow them I may want to temporarily not allow them for network issue reasons. I for one wouldn't allow a user to use external links for the avatar to begin with.
Drupal version 6.x is closed to new features so I've moved the issue to version 7.x.
Comment #8
dave reidComment #9
jeffschulerAllowing comment threads and forums to constantly yank many images from many disparate external sources seems like a page-loading nightmare that no admin would really want, particularly because there'd be no straightforward way to limit image size.
However, it could be useful for a user to get their pic from an external location, then be re-sized (as currently, or with imagecache) and stored locally.
It can be annoying as a user to set up a profiles from another machines where you don't have images stored. This is a problem that Gravatar and OpenVatar seek to solve, but they don't solve every user's purpose.
I don't know that this functionality belongs in core, but it might make a nice contrib module.
Comment #10
dave reidThis functionality would actually make the job of contrib 'avatar' modules like Gravatar much, much easier. Currently we have to completely override theme_user_picture. In this new case, we could just change $account->picture = 'http://gravatar.com/avatar/md5hashofemail'; and it would work automatically. We don't need to expose an option for this because the only way users can change their pictures is if they upload them, which makes them a local picture. Assigning myself to reroll and write tests.
Comment #11
dave reidRe-rolled for HEAD.
Comment #12
dries commentedIt seems like this code would probably go away once we Field-ified profile module...
Comment #13
dave reidI guess I'm not sure. How exactly would this be replaced by a field?
Comment #14
dave reidPlus, user pictures are a part of user.module, not profile.module. :/
Comment #15
kwinters commentedRe: the admin option above - this absolutely has to be disabled by default, and enabled either by turning on a module or enabling a permission / setting.
Arbitrary image URLs are an XSS liability, and we should warn the site admin that this is the case.
Comment #16
dave reidThe only way this is going to happen is if a module manually sets $user->picture = 'http://myimage.jpg'. This is not possible to do in the interface at all. There's no option needed, this is just about making contrib easier. It would be presumed that if someone were to install the Gravatar module, they want Gravatars, which are not local images.
Comment #17
kwinters commentedAlright, it's reasonable for the interface module to be in charge of permissions / warnings, but the code block in core still needs to say that it is their responsibility and that it is an issue. It's too important to just hope they figure that out, particularly since that kind of security issue is normally handled by core already and they might assume it to be the case here as well.
In the particular case of Gravatars, restricting it to the right domain seems to be sufficient behavior for the module.
Comment #18
MichaelCole commented#11: 187374-user-picture-external-D7.patch queued for re-testing.
Comment #19
catchComment #20
robloachYup, Drupal's User Pictures system hurts my brain.
Comment #21
dave reidI'm starting to flip on this that we need to make it easier to grab external images and save them locally, rather than supporting external images. I'm experimenting with this with http://drupal.org/project/user_picture.
Comment #22
moshe weitzman commentedFYI, #1292470: Convert user pictures to Image Field.
Comment #23
robloachI like this approach more. Hot linking images can result in some very undesired affects, like the host switching out the image with something not so awesome.
I think we might even want to close this one and think about #1292470: Convert user pictures to Image Field instead.
Comment #26
jhedstromIs this still needed? Also not sure why it got changed back to a bug.
Comment #27
dpiReasonably sure we don't need this. Since pictures are fields now (#1292470: Convert user pictures to Image Field), and we have https://www.drupal.org/project/avatars as POC on how to load remote images into field.
Comment #37
smustgrave commentedMoving to outdated since there hasn't been a follow up since moving to PNMI 6
years ago.
If you feel this is still an issue please reopen with an updated issue
summary.