If you specify a default user picture (under admin/user/settings) that is larger than the maximum picture dimensions, the dimensions are not enforced for that image. Why can't the default user image be an upload field and work just like a user uploading their own user picture? This would also eliminate some confusion about what exactly should be specified for the path of the default user image: Should I specify a relative path? Relative to what? How do I get the default image there? Should I specify an absolute url? I think this would be +1 for usability.
Comment | File | Size | Author |
---|---|---|---|
#4 | 305802.default.picture_4.patch | 5.31 KB | Dave Reid |
#3 | 305802.default.picture_3.patch | 4.77 KB | maartenvg |
#2 | 305802.default.picture_2.patch | 4 KB | Dave Reid |
#1 | 305802.default.picture.patch | 3.94 KB | Dave Reid |
Comments
Comment #1
Dave ReidInitial patch ready for review. Will need to re-roll if #142995: Add hook_file and make files into a 1st class Drupal object makes it in before this.
Comment #2
Dave ReidForgot to add a form encoding type so the file would actually upload. Confirmed patch uploads, resizes and deletes default picture successfully.
Comment #3
maartenvg CreditAttribution: maartenvg commentedI've tested this patch, and came across an error. On a fresh install (or when the user_pictures hasn't been enabled before) when there isn't a 'pictures' directory yet, this patch will upload the default picture before the goal directory has been created. Currently the directory is created after the entire form has been processed and is shown to the user again, while the uploaded file is moved to the goal directory during form validation.
I've attached a patch that fixes this, by creating the folder during the validation process. And +1 for this feature!
Comment #4
Dave ReidThanks for that fix maartenvg! I modified it a little bit to use $form_state['values']['user_picture_path'] instead of variable_get since if the user is changing the picture path, that variable hasn't been saved yet. This also cleans up the 'picture_delete' and 'picture_upload' variables that unnecessarily get saved into $user->data from the user edit form.
Comment #5
webchickWow. This totally qualifies as one of those "duh" things that we completely overlook because we're all so used to Drupal working this way. Big +1 to seeing this fixed.
However, because this has gone unnoticed for 100s of years, it leads me to believe that this is a relatively obscure setting in Drupal that not many people use. And you know what that means? It means...... we need a test for it, because we're not likely to ever catch it if it breaks. ;)
Also, user_validate_default_picture needs some PHPDoc to satisfy my inner control freak. ;)
Comment #6
Dave ReidAfter discussion with webchick, need to:
- Add default user picture test to user.test
- Document the user_validate_default_picture function
And there's webchick's updated before mine...
Comment #7
Dave ReidBroadening issue a little to incorporate some fixes found in:
#131573: Validate maximum picture dimensions
#27234: Maximum picture size help text in profile no longer needed
#222036: Usability: User picture system is confusing
#141541: Files directory check doesn't disable uploads if check fails, in admin/user/settings
Comment #8
maartenvg CreditAttribution: maartenvg commentedDavid, are you working on this or is it fine for me to start incorporating the other issues?
Comment #9
Dave ReidI've actually got most of the work done I just need to get some tests written today to wrap this up!
Comment #10
Dave ReidWill split out requiring image toolkit for user pictures to save a kitten and help me focus on this patch.
Comment #11
Dave ReidComment #12
Dave ReidComment #13
Dave ReidComment #14
quicksketchSubscribe
Comment #15
tonyn CreditAttribution: tonyn commentedsubscribe.
Comment #16
webchickFeatures go into Drupal 8 now
Comment #17
geerlingguy CreditAttribution: geerlingguy commentedCrud, and subscribe.
Comment #18
larowlan+1 for this as well as making the setting more portable, it doesn't move well between sites using strongarm/features because of the xxx bit in the value (eg sites/xxx/pictures/some-default.png)
Comment #19
RKS CreditAttribution: RKS commentedUsing D7 and default picture does not pass and get resized. Looks like this didn't get fixed for D7?
I would say this is actually a bug since it is all about core now since there is no more imagecache for D7. I would also argue that this is a major instead of normal after all this time but I won't upgrade it and leave that to someone else to agree first.
Comment #20
NancyDru+1 for fixing this and +1 for back-porting to D7 (D6 would be nice, but I won't hold my breath).
Comment #21
RKS CreditAttribution: RKS commentedI actually think I was talking about something completely different than everyone else. In my case D7 doesn't pass the default image through the image styles if you set the path something like sites/files/pictures/default.png because it makes the file private. You have to set the path to public://pictures/default.png (relative to the path you set for public:// that is.)
That's what I was talking about in my post and didn't really notice everyone else was referencing some other problem. Sorry.
Comment #22
LarsKramer CreditAttribution: LarsKramer commentedIt seems to me this issue's summary talks about two things:
1. Having a better interface, as also suggested by the title (an upload button for example). That would be a feature request.
2. The default user image not being resized. That would be a bug report which seems to be related to these other two issues:
#799178: User default picture path incorrect when run through image styles
#1371742: Default image not being resized
Comment #23
sunComment #24
alexpott#1292470: Convert user pictures to Image Field changed user pictures to an image field - just tested and it appears that the default user image is resized using image styles so I think this is a won't fix for drupal 8. Moving back to Drupal 7.