Users should still be able to upload a user picture and override Gravatar
Dave Reid - November 15, 2008 - 02:12
| Project: | Gravatar integration |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Dave Reid |
| Status: | closed |
Description
Users should still be able to upload a user picture that would override any Gravatar image for that user. Currently when Gravatar is enabled, we're hiding the picture upload form elements in the user/x/edit page.

#1
Agreed. That was the previous functionality and the best.
The current method actually lets you upload a image but you have to set the enable/disable gravatar by users option then the user has to disable gravatar, submit the form, then upload an image. All very unnecessary and complex. If the user uploads a specific picture to the site that should take precedence over their gravatar just as their account email should be used unless they enter a different specific email to use for gravatar.
In fact, the hook_help still specifies the proper behavior.
#2
I am unsure of the developers intentions but on second look it appears to me that the only reason that you would want such behavior is to force users to only be able to use gravatar and not upload an image.
If that is the case the option in admin setting should be "Force users to use only gravatar" or "Disable user picture upload". That would only be one setting and would give the best possible and most usable way to get both features.
It would not burden users that can do both and force those that can not.
#3
My train of thought is to use the following options in admin/user/gravatar:
[x] Enable Gravatars
[x] Gravatar enabled by default for all users
[ ] Allow users to change or disable their Gravatar
[ ] Disable user picture upload form
Default values have an 'x'
#4
I'm not even sure why we need the 'Enable Gravatars' option. Why not just disable the module? It's assumed if you enable the module, you want the feature enabled. Seems silly to have that option.
#5
And there really is no need for the option 'Gravatar enabled by default for all users' because there is the 'use gravatar' perm that needs to be set, which is nice to enable for only certain roles.
So that leaves us with only:
'Allow Users to change or disable their Gravatar' - What is the use case for this option? It seems to be just extra complexity. I would leave it as I mentioned before and let your drupal picture, if you have one, to override your gravatar. Then you just need to delete your user picture if you want to use your gravatar again. To be even more user friendly you could use the form alter to change the 'Delete Picture' checkbox label (shown when you have a photo uploaded, screenshot attached), to say 'Delete picture and enable gravatar'. That saves a per user setting, which is always expensive, and uses the current system without adding complexity.
Leaving us with just 1 option to be able to force users to use gravatar only, which might be better as a perm instead of an option so that you can adjust by role.
#6
BTW, I created a separate task (#334657: Remove custom gravatar e-mail field) for removing the 'custom gravatar e-mail' field in the user account setting. Gravatar accounts can have multiple e-mails associated per account, so why are we making this more complex than just using the e-mail provided by the user for their account?
#7
@dragonwize, so what I get from your suggestions is have two permissions: 'use gravatar' and 'can disable gravatar'?
#8
Correct.
I agree perms should always be positive like 'can disable gravatar' but not sure that explains exactly what that option does enough. It doesn't convey to me that they user will not be able to upload a picture.
Brainstorming:
can override gravatar
use upload
can upload picture
can upload gravatar override
Nothing yet is really striking out at me as the best answer. You have any other suggestions?
#9
New release out today (6.x-1.5) will now allow users to still be able to upload a user picture. I'll take a look at adding a new permission for disabling the upload form.
#10
#11
Automatically closed -- issue fixed for 2 weeks with no activity.