Problem/Motivation

Is there a reason why users cannot add a picture to their drupal.org profile? groups.drupal.org uses them, but the main drupal.org site does not.

Proposed resolution

  • We allow registered users to upload an image and use it as their profile avatar.
  • If no image is uploaded, we use the user's registration email to fetch an avatar from a 3rd party service such as gravatar.com (there's a contrib project for this: http://drupal.org/project/gravatar)
  • User can opt-out so that no image is displayed.

Remaining tasks

This issue is postponed, awaiting the outcome of comment #66 and also this issue #1296176: Use Association Membership information via JSON which provides mechanism for uploading picture once and then showing it on all sub-sites.

A dev site was set up for this task: #1508364: I want a drupal.org development site for user profile pictures

There are concerns of how this will impact performance. We should test this.

If we decide to also support an external social-service-like provider for user profile images such as gravatar.com, we should then perhaps consider a mechanism that stores profile pictures locally too as a fallback for cases when these services are temporarily down, permanently closed or made commercial in the future.

Related contrib projects and issues

Gravatar integration

#334630: Cache gravatar images locally

Imagecache External

...a utility module to allow you to use imagecache(D6)/image derivatives (D7) with external images.

ImageCache Profiles

...allows you to set user profile pictures that are consistent throughout your site and allows avatars on the user profile pages, nodes and comments to be a different size.

#1300064: Integrate imagecache external with imagecache profiles

User interface changes

You can find various mock-ups of how things might/should look in comments bellow. The UI changes will be:

  • UI for registered d.o users to be able to upload/set an image as their profile avatar.
  • Both anonymous and registered users will see profile pictures of registered users in various places. The following places were suggested so far (but no final decision made yet):
    • Issue nodes
    • Issue comments
    • Forum nodes
    • Forum comments
    • Documentation nodes
    • Documentation comments
    • Project node author
    • Project node maintainer lists
    • Commits
    • Release nodes
    • Listings of followers
    • User profile page

API changes

???

Original report by Mark Carver

...the original report is the "Problem/Motivation" section above + the suggestion to use http://drupal.org/project/gravatar

Files: 

Comments

markcarver’s picture

Bump

markcarver’s picture

Is this the appropriate place for this question?

kiamlaluno’s picture

Title: User Profile Pictures » Enable the support for user profile pictures
VM’s picture

The problem I forsee with this on drupal.org is the posts that already take a long time to load due to many comments. Adding more requests to long threads isn't going to be of benefit.

Webmasters can't do much about this as it would have to come from higher up. Infrastructure team may have to weigh in on this request.

Dave Reid’s picture

I don't see a problem with just turning this on right now. Pictures would be served locally.

webchick’s picture

Subscribing. And I'm curious about why this is too. AFAIK the original d.o redesign mocks had user pictures in them.

heather’s picture

Subscribe.

Let's do eet!

What does a to-do list look like?

* Create, approve and update design to accommodate images of the appropriate sizes.
- Within thread
- On profile
- On summary sidebar blocks (For "Topic pages" for example, for a hypothetical "who's following" block).

* Slurp images from g.d.o? Or people add in a new updated image?

* Test new design on sandboxes.

* Implement update to profiles.

* Inform ppl!

tvn’s picture

Issue tags: +prairie, +topic pages

subscribe and tags

laura s’s picture

+1.

dww’s picture

Issue tags: +flag integration

+1 to this. It'd be useful for many things, for example #1304558: Provide a page showing all the users following a given issue.

We'd have to think about how we want these to look on comments on issues (which are special-cased from other comments on this site). There are a lot of questions to answer about exactly where and how these would appear throughout d.o:

Issue nodes: yes
Issue comments: probably
Forum nodes: yes
Forum comments: yes
Documentation nodes: probably not
Documentation comments: probably
Project node author: probably not
Project node maintainer lists: probably?
Commits: yes (although it can get complicated with both the commit author and the committer (which aren't always the same identity).
Release nodes: no
Listings of followers: yes
... ?

All those places I said "yes" or "probably" should ideally get mockups or a basic spec for exactly how they're going to fit into each of these pages. Should probably copy this list into the issue summary so it can be collaboratively fleshed out and finalized.

So, I think there's a lot to design and get right before we just turn these on. But, I'd really like to see it happen, so let's get designing... ;)

Thanks!
-Derek

cweagans’s picture

I'd really like to see this happen - it'd make attaching names to faces MUCH easier. :)

tvn’s picture

FileSize
74.91 KB
228.01 KB
127.67 KB

I am not sure about adding pictures to issue comments. Issues often are huge and contain lots of into which is hard to process as is. Not sure it is good to add even more stuff on these pages.

So my list would be:

Issue nodes: no
Issue comments: no
Forum nodes: yes
Forum comments: yes
Documentation nodes: no
Documentation comments: yes
Project node author: no
Project node maintainer lists: yes
Commits: no idea here
Release nodes: no
Listings of followers: yes
User profile page yes

I did some mock-ups for the ones where I said yes:
User profile page - size of user pic 85x85 px
user profile

Forums
main node - user pic 65x65 px
comments - 40x40 (documentation comments I suppose should look the same)

forums

Project page - user pics 28x28 px

project page

greggles’s picture

Great work on the mockups, tvn!

Doing it on issue nodes/comments would be a huge win for me for scannability. If I look at a long issue I want to be able to find comments by people I trust as quickly as possible. I can scan avatars many times faster than I can scan usernames. If they are too big we can just use an image style to make them smaller.

webchick’s picture

I agree. Seeing it on the maintainers block like that makes me drool and really want it for issue nodes/comments as well. :)

GREAT work, tvn!! Those mocks look fantastic.

cweagans’s picture

Great work on the mockups!

I'd like to see the pictures be a consistent size everywhere we use them, though - the ones on the maintainers block are pretty small. Is there any reason not to use the full size picture and split the data onto multiple lines?

So rather than:

dereine - 1610 commits
last: 1 day ago, first: 1 year ago

We'd have:

dereine
1610 commits
last: 1 day ago
first: 1 year ago

(or something to that effect)

That way, we could use the full size user picture instead of a miniaturized one.

If we wanted to get REALLY crazy, we could turn it into a grid view instead of a list view. I'll open another issue to talk about this more, but the gist is that we'd have user pictures and usernames. When you hover over the picture, you'd get a little popup bubble with commit data.

webchick’s picture

Hm. I like the mockup the way it is, personally. These pictures are not the primary piece of data in that block, the information about commits is. Makes sense to use a smaller version of the picture. So too with comments vs. nodes.

There's no performance penalty as far as ImageCache is concerned for having multiple sizes, so let's go with what looks nice. :)

dww’s picture

-1 to always using the same size. I think "inline" avatars make perfect sense in some places, as elegantly demonstrated by tvn's (awesome!) mockups.

Re: "Is there any reason not to use the full size picture and split the data onto multiple lines?"

Yes. ;) Because we don't want that block to take up all of the "above-the-fold" right sidebar on project pages.

cweagans’s picture

FileSize
159.93 KB
169.61 KB

These pictures are not the primary piece of data in that block

Actually, since the block is titled "Maintainers for whatever", I'd think it'd be focused on the people rather than the commit information.

I was thinking something like this:

core-faces.png

When you hover over a face, you'd get something like this (but without my artistic deficiencies):

core-faces-hover.png

webchick’s picture

No, please don't make me mouseover for the important information I want to know. :(

webchick’s picture

Also, that breaks a pattern. Nowhere else does the user picture give me more information when I hover over it, so I'm not sure how a user would ever discover that this happens here.

greggles’s picture

separate issue: I think usernames/avatars *should* show relevant info. David Eaves suggested a "new" user flag and "Learning English". I'm not opposed to the pattern this introduces, but I agree with webchick we shouldn't have to hover to get the most relevant info.

killes@www.drop.org’s picture

Since this is likely to increase the amount of traffic we use, I want to point out that having a avatars of the same size would lend itself better to browser caching.

killes@www.drop.org’s picture

I also like to suggest to have an optional "no graphics" subtheme for those who prefer fast pages over ugly faces.

webchick’s picture

Eh, that can be done with user styles IMO. The caching bit is a good point though.

killes@www.drop.org’s picture

User styles allows me to hide the avatars, however I'll still need to d'l them unless I employ html rewriting. Don't think user styles do that.

tvn’s picture

FileSize
117.26 KB
118.33 KB

So issue page:
Only local images are allowed.
I also think we could consider moving reply links on top: http://drupal.org/files/issue-page-2.png

webchick’s picture

Hm. I can see why you were leaning against having these in the issue queue. #27 still looks like it needs work.

What does it look like if there's a <br /> between "Posted by klonos" and "on October.."? The other images look great because the data they're next to spans two lines.

Another thought is putting the picture floated left underneath the "#xxx" in the comment.

tvn’s picture

FileSize
97.07 KB
96.86 KB

Yeah, was thinking to try that too. Looks like this :

issue page 3

Or :

issue page 4

cweagans’s picture

I like the first one - looks pretty good :)

laura s’s picture

First one in #29 is nice. :)

moshe weitzman’s picture

Not a big deal, but I think gravatar would be better than core user picture. Lots of folks have already specified a gravatar so the site would look awesome on day one. And not just one site, gravatar works across all our sites so we don't have to do any user profile sharing across all d.o. sites. If we go this way, IMO we can simply abandon the gdo images that folks have uploaded. We could just provide a little notice for folks to copy their pics to gravatar.

mototribe’s picture

great to see that d.o. is becoming more "social". Little things like profile pictures make a big difference IMHO.

A popup over the username/userpicture to show more info like "join date, number of commits, etc" would be great too.

+1 for gravator, I already use it on StackExchange and StackOverflow. Plus have a module for that: http://drupal.org/project/gravatar

webchick’s picture

markcarver’s picture

I am ecstatic to see so much discussion on this topic. I know this is kind of out of my domain now... however if there's anything I can do to help, please let me know!

Thanks everyone!
Mark

lisarex’s picture

+1 for enabling profile pics

Interesting re: using Gravatar, but since we have profile pics on g.d.o., it would definitely enforce the notion that d.o. and g.d.o. are separate sites; I personally have a non-face Gravatar, but I have a face on g.d.o. If other users use separate pictures, it would negatively impact the ability to scan the avatars for someone you know.

Unless we decide to use Gravatar across all *.d.o. sites as well.

webchick’s picture

I'd prefer to stick as close to stock Drupal as possible, so that means just using the normal user picture upload field.

Dave Reid’s picture

Hrm, I still want to throw support behind Gravatar. There's no need for us to be insistent that we have to use Drupal core features when there is a service out there that is widely supported and would avoid having to serve resources off of Drupal infrastructure. I'm going to be pushing that we replace user pictures in Drupal 8 core with Gravatar by default as well.

Dave Reid’s picture

Granted, we could always add the Gravatar module to d.org which will allow people to upload their own avatar, or to use a Gravatar if one is not uploaded which would work for most users.

killes@www.drop.org’s picture

-- for external services.

Dave Reid’s picture

greggles, could you send me the results of "SELECT MD5(mail), picture FROM {users} WHERE status = 1" from the g.d.o database so I could check how many users have a Gravatar compared to how many people have a user picture uploaded?

cweagans’s picture

+1 for Gravatar. I can understand killes' hesitation, but I think it'd be a good idea in this case. Gravatar is pretty standard.

Steven Jones’s picture

+1 for gravatar, much more useful than having upload another image to yet another site.

tvn’s picture

I am strictly against using Gravatar, unless there still will be the possibility to directly upload a picture on d.o, for those who don't want to use that service for one reason or another. For example, I might want to use face avatar on d.o and not want it to show up on any other site using Gravatar service. I generally think there always should be an option for users, we should not force people to use external services.

Michelle’s picture

If Gravatar and core user pictures can work together, that sounds like the best plan. I'm -1 on adding user pictures in general but I know I'm in the minority. Requiring some 3rd party account for it sounds even worse. If you're going to have them, you should be able to have one without having to go sign up on some other site first.

Dave Reid’s picture

Gravatars (as it works with the module) will always be overridden if you upload your own picture.

Gerhard Killesreiter’s picture

Just for the record: I am not against gravatar because it would require me to have an account with them in order to display a picture at d.o - I don't plan to upload one anyway.

I am against using an external service for user pics since this will allow that external service to track users on drupal.org.

cweagans’s picture

Until #46, I didn't realize that gravatar.module allowed users to override their user pictures by uploading one. I really really like this plan - all users will get gravatar data unless they override it manually. Seems like a really good solution.

@#47, they *can*, but why would they? Also, if a user is really worried about it, then they can upload their own user picture to their profile and it's no longer an issue.

Crell’s picture

What if someone has a Gravitar picture but for whatever reason doesn't want anything on d.o at all? (Says the guy who has a very old picture on g.d.o and nowhere else and has considered removing the g.d.o picture, too...)

markcarver’s picture

No secret I'm in favor of Gravatar +1000. That being said, I would like to expand on what Dave said in #46:

Gravatar is only an enhancement module. It does not replace the existing functionality of Drupal and it's user pictures. Users will still be able to manually upload a picture to d.o. The purpose for using a module/service such as Gravatar is that it allows people to change their profile image across multiple sites, instantly. It is already used by many sites, including GitHub and StackOverflow just to mention a couple. Adding Gravatar would only increase the feature set of d.o, not diminish it.

The Gravatar module simply checks if the users email is attached to an account with their service. If it exists, it will use it. If a user manually uploads a picture on d.o, it will then use that one. The following is the workflow logic that is followed (in order of what's checked first):

Manual Upload (drupal) > Gravatar (external) > No picture/Default Picture (drupal)

I would also have to agree with cweagans in #48, if you don't want a picture then don't upload one and don't use services like Gravatar. Otherwise, let us social butterflies enjoy a little more color on d.o :)

As far as the external service debate going on, it would only pertain to the users who use the Gravatar service. Obviously for people like us who have an account with Gravatar, we are already in favor of letting Gravatar provide sites with our profile image. We enjoy the simplicity of not having to constantly change our image across multiple sites. Why punish the very people who have already given their permission to use it?

markcarver’s picture

@Crell in #49, it's been a while since I've used the Gravatar module (see original posting date hehe). But I'm pretty sure there's a checkbox that allows you to disable the image pulled from the service.

webchick’s picture

So instead of talking/theorizing, who wants to spear-head a d.o sandbox to get started on an implementation we can see/touch?

Gerhard Killesreiter’s picture

@Mark: You are quite mistaken. If I see _your_ gravatar pic on d.o, gravatar can in theory track _my_ movement on d.o and in-fact elsewhere if they set a cookie. I am not aware they are setting cookies for the time being, but this may change. In any case they can gather statistical data about drupal.org. Considering that gravatar is run by the wordpress guys this is to be considered too.

Michelle’s picture

@Crell: I believe it's tied to your email so you could just use a different email, couldn't you?

markcarver’s picture

@Killes in #53: I'm not entirely mistaken and I stand by my points. True enough, you do have a valid point, but that is a minor logistical issue: #334630: Cache gravatar images locally, problem solved. And yes, Automattic bought Gravatar back in 2007. But what does that matter? It's not like we're going to be solely relying on Gravatar. It's only there to enhance the existing user experience. Hypothetically, say that they decided to shutdown the service or even somehow blacklist us because we're "Drupal". That impacts us how? Uninstalling the module? Users that have already uploaded manual pics to d.o wouldn't be affected. And those that did allow their Gravatar pic to be used would just have to upload a new pic, if they wanted.... worst case scenario of course.

Crell’s picture

Michelle: Google's asinine email handling causes me enough grief as is. No, I am not adding another email address to my Internet mix.

markcarver’s picture

Michelle’s picture

@Crell: Fair enough. I have 3 that I use routinely so I guess I'm just used to having multiples. I won't use Gravatar either way so it doesn't affect me as long as it's optional.

drumm’s picture

Project: Drupal.org webmasters » Drupal.org customizations
Version: » 6.x-3.x-dev
Component: User account » User interface

The hard part isn't turning on regular core profile pictures or dealing with Gravatar. We should have a single user picture across all subsites, we should not ask people to upload the same picture to Drupal.org, groups.drupal.org, association.drupal.org, all DrupalCon sites, and any others that start using pictures. This issue needs to be about making user pictures available on all sites.

LoMo’s picture

I agree that user pictures *should* ideally be the same across all d.o sites, and I think Gravatar is a simple way to make it easy for those who use the service and don't want to bother uploading pictures anywhere else. I'm in favor of using Gravatar and allowing for the following options:
1) instead use an avatar just for d.o sites (anyone who uploads a user image)
2) just use the Gravatar-uploaded image (default)
3) show no image, even if Gravatar is available for associated email (opt-out checkbox)

klonos’s picture

I'm in favor of this too. I personally don't have a Gravatar account and I probably never will, but I still think this would be a great feature since most people tent to be "social" nowadays. Never mind my personal preference to not having a Gravatar account, I still use the contrib module on my sites and my customers' if they agree. We have to admit that it does enhance the social UX of a site ...almost atomagically!

We need to update the issue's summary with the concerns raised here (such as the possible performance hit) so we don't miss them as we implement this. One thing that wasn't discussed here is the possibility of gravatar.com being shut down (or locked or made commercial) in the future and what this means for d.o registered users that use this service for their profile pic (this is related to #334630: Cache gravatar images locally). For this specific concern, I think we should consider:

1. using Imagecache External to store the largest available image locally,
2. then process it with imagecache for our needs (for cases like when we need various avatar sizes in different parts of d.o as mentioned above for example),
3. we have it so that every while (cron run perhaps) a fresh version of the images is pulled from gravatar.com

This way, instead of having a couple of dozen requests (depending on the number of user comments) to an external source each time a forum/issue page is viewed, we serve the local version. I realize that this means that if users update their gravatar their change won't be "instant" in d.o. I guess we can either accept this as a trade-off or we figure a way to allow users to manually request their pic to be re-fetched from gravatar.com.

I read in #1508364: I want a drupal.org development site for user profile pictures that there was created a userpics dev site. Is that still on? Who's working on it? That info should be in the issue summary too.

klonos’s picture

I've updated the issue summary. Please take a look and update as you see fit or add anything I might have missed.

klonos’s picture

Another thing that might be worth considering/documenting is the upgrade path to D7 for the Port Drupal.org to Drupal 7 initiative.

klonos’s picture

Issue summary: View changes

...updating the issue summary to follow the issue summary standards + adding a few notes from various comments so far.

LoMo’s picture

Well, the Gravatar module is available and stable for D7 and otherwise D7 is just much better equipped to handle images. I don't think we need worry too much about the "porting to D7" of this feature. See #55 for if Gravatar shut down (no big deal, users just upload a new avatar to d.o, if they choose).

klonos’s picture

Yes, I'm aware of these facts, the reason I'm mentioning things like these is because I don't want them to be "considered given" for some (us) and then others coming and asking again and again "just to make sure". They should at the very least be documented so that others don't wonder in the future and in order to reassure people that inclusion of the Gravatar project for example doesn't hinter our upgrade to D7 of drupal.org. As for the chance of gravatar.com closing in the future, again people should know that we have a "fallback" in place and that we've taken steps to make sure everything runs as smoothly as possible in case this ever happens ;)

Senpai’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +Drupal.org D7

This issue is postponed until there's a clearly defined upgrade-map-to-d7 document which shows me how much this proposed change will affect our http://drupal.org/community-initiatives/drupalorg/drupal7 initiative.

1. Does the gravatar.module upgrade path work flawlessly with our current d.o user accounts?
2. How much effort will need to go into theming new D6 pictures sitewide, and how much time will that increase the D7 Bluecheese theming effort?
3. How many D6 imagecache presets will we need, and do they all upgrade themselves perfectly into D7 without errors?
4. What does the "User can opt-out so that no image is displayed (see issue summary above)" workflow look like, and will it be different in d6 and d7? Will they be able to opt-out as they sign up with our site, or will they have to come back and disable their newly auto-added picture later by editing their account?

Senpai’s picture

Title: Enable the support for user profile pictures » Enable user profile pictures on drupal.org

Clarifying the title as belonging to www.drupal.org and not all sub-sites.

Senpai’s picture

Issue summary: View changes

...added ImageCache Profiles contrib project to the related projects and updated/moved things here and there.

tvn’s picture

Title: Enable user profile pictures on drupal.org » Enable the support for user profile pictures

Changing the title back because as per #59 -
"This issue needs to be about making user pictures available on all sites."

User pictures won't be turned on only on drupal.org but on sub-sites as well.
As discussed today during Drupal.org office hours - problem of uploading picture once and then showing it on all sub-sites is the main blocker for this issue.

It won't be possible to do it via Bakery in Drupal 7. So we need to use data sharing mechanism, which is in work in this issue: #1296176: Use Association Membership information via JSON and use it for all profile info from Drupal.org, including profile pictures.

tvn’s picture

Issue summary: View changes

Adding a 'postponed' comment to the summary.

markcarver’s picture

Does anyone else have the time to tackle this?
#1508364: I want a drupal.org development site for user profile pictures

I unfortunately do not have as much time as I thought I would to tackle this task personally. If not, the dev site should be closed until this can be accomplished.

philosurfer’s picture

+1 Gravatar. Make life easy for now.

tvn’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Status: Postponed (maintainer needs more info) » Postponed
Issue tags: -flag integration, -Drupal.org D7

This will have to wait for D7.

Oleksa’s picture

I is very easy to create gravatar-like service (without gravatar) from any drupal site, for example I use this code to achive it (avatar based on user_id and not on email) very handy for any drupal multisite with common user table:




function ok_avatar_menu() {

  $items['userpic/%/%'] = array(
    'page callback' => 'ok_avatar_arguments',
    'page arguments' => array(1, 2),
    'access arguments' => array('access content'),
    'type' => MENU_CALLBACK,
  );

  return $items;
}


function ok_avatar_arguments($uid, $size) {

  // Make sure you don't trust the URL to be safe! Always check for exploits.
  if (!is_numeric($uid) || !is_numeric($size)) {
    // We will just show a standard "access denied" page in this case.
    drupal_access_denied();
    return;  // We actually don't get here.
  }
//todo check http://drupal.org/node/145279 http://api.drupal.org/api/drupal/includes%21cache.inc/function/cache_set/7 to use static cache
if (!cache_get($uid . 'ok_avatar_cache' . $size)) {
    $account = user_load($uid);
  $avatarsize = array(1=>'thumbnail',2=>'medium',3=>'large',4=>'32x32');
 
  //pls create and put to /pictures folder deafault image : default.png	
  //todo: put default avatar to module folder $base_url . '/' . drupal_get_path('module', 'ok_avatar') . '/default.png'
  $uri = isset($account->picture->uri) ? $account->picture->uri : 'public://pictures/anonim.jpg';
	
  $url = image_style_url($avatarsize[$size], $uri);//do all your time taking complex calculations here
  cache_set($uid . 'ok_avatar_cache' . $size, $url, 'cache', 60 * 60); //stores in cache table 1 hour
    
  } else {
    $return = cache_get($uid . 'ok_avatar_cache' . $size);
    $url = $return->data;
  }
  $extList = array();
  $extList['gif'] = 'image/gif';
  $extList['jpg'] = 'image/jpeg';
  $extList['jpeg'] = 'image/jpeg';
  $extList['png'] = 'image/png'; 
  
  
  $imageInfo = pathinfo($url);
  $ext = isset($imageInfo['extension']) ? $imageInfo['extension'] : NULL;
  $contentType = 'Content-type: ' . $ext;
  
  header("Cache-Control: max-age=3600"); //stores in cache 1 hour
  header ($contentType);
  
  readfile($url); 
}


this is one of the way, an there are a lot more like using http://drupal.org/project/imagecache_external

Oleksa’s picture

Issue summary: View changes

adding blocker issue

mgifford’s picture

Well, Drupal.org is upgraded to D7. There are other ways to do this of course, but it seems like https://drupal.org/project/gravatar will probably hit a lot of users the fastest. There are a million users now, so finding a way to simplify it for users would be good.

Having images on comments & posts would make it feel more like a community.

mgifford’s picture

Issue summary: View changes
Status: Postponed » Active
dddave’s picture

So drupal.org shall run a service that requires users to create a wordpress account?

I think the Gravatar solution is dead.

edit: My snappy tone isn't direct @mgifford but a result of my frustration with Gravatar as such.

mgifford’s picture

Understandable.. So back to #72?

moshe weitzman’s picture

The gravatar module lets users upload a local picture and uses that by default. It just uses gravatar.com to show pictures for folks who prefer not to upload locally. And you can even disable your gravatar image in your profile if you don't want your public gravatar image being shown on a given Drupal site. I think all the bases are covered here.

Dave Reid’s picture

BTW when I last looked at the MD5 hashes of all groups.drupal.org account, there was a significant chunk of users that had Gravatars already. Gihub even uses Gravatars, but lets you specify which email address to use when looking it up.

mgifford’s picture

The summary of this issue is quite good. The first step is to just enable registered users to upload an image and use it as their profile avatar.

That's pretty trivial. Why don't we start there (this week even)?

We can then confirm how we want this to be placed and what the impacts will be for performance and what not.

Given that there are a million users, I do think we need to define a default image or behavior when a user hasn't uploaded an image. There will probably be a lot that never do.

If folks have provided a Twitter or Google+ account we can suggest that they use the image that they have there. This would help facilitate more folks uploading images. It could just be suggested in /user/UID/edit when someone goes there and doesn't have an image selected.

https://dev.twitter.com/docs/api/1.1/get/users/show
https://developers.google.com/+/api/latest/people/get

If they don't have either of those, then it seems pretty trivial to fall back to using gravatar:
https://en.gravatar.com/site/implement/images/php/

Those are details that we can work out later. The first step is enabling photos with user accounts, so let's get on with that.

markcarver’s picture

Related issue has screenshots for this issue as well.

mgifford’s picture

The screenshots are well worth looking at. Mark's done an amazing job!

drumm’s picture

mgifford’s picture

I've now gone through most of the issues in the https://groups.drupal.org/prairie-initiative group.

I do think that adding this will help make our community stronger.

Gaelan’s picture

Is there any way I can help out w/ this?

drumm’s picture

The rough todo list is:

  • Write a script to move groups.drupal.org user pictures into place for Drupal.org. This can be done with the users.init column in groups's database. The query should output mv commands that can be run on our media server.
  • Make an a child issue for user picture styling of #936304: [META] Style issue comments and implement. We should have them for all comments, not just the issue queue.
  • Use #556666: Sync hooks: Enable sharing of arbitrary data to implement pushing the user pictures out to subsites. All we really need to sync is whether a picture exists or not, the sub site has the master site's uid, so it can construct the URL in the drupalorg_crosssite module.
  • Update this issue's summary.
drumm’s picture

Assigned: Unassigned » drumm

https://drumm-drupal.redesign.devdrupal.org/user/3064 is an example page with a user picture.

The page layout is based on some work Dani Nordin has been doing for the DSWG Community tools team. There is more to come, it is in the design phase right now.

I've also updated bakery on all Drupal.org sites on D7, which will allow sharing user pictures across sites.

mgifford’s picture

Nice improvement for the profile page. Great to see that bakery is updated to allow images.

Dave Reid’s picture

I hope at some point after this lands we'll reconsider allowing Gravatars for people that want to use them. I don't want to have Drupal.org be yet-another-site-that-makes-me-upload-my-avatar.

  • Commit 0bdadb0 on 7.x-3.x by drumm:
    #957320 Enable the support for user profile pictures
    
drumm’s picture

The basic support for profile pictures has been turned on. I'm importing pictures from DrupalCon Austin with:

$result = db_query("SELECT substring_index(substr(u.init, 17), '/', 1) uid, f.uri FROM users u INNER JOIN file_managed f ON f.fid = u.picture");
$rows = array();
foreach ($result as $row) {
  $row->uri = file_create_url($row->uri);
  $rows[] = $row;
}
print_r(serialize($rows));

and on the Drupal.org side:

$data = unserialize(file_get_contents('/home/drumm/foo'));

foreach ($data as $row) {
  $account = user_load($row->uid);
  if (empty($account->picture)) {
    $image = drupal_http_request($row->uri);
    if (!isset($image->error)) {
      print $account->uid . "\n";
      $file = file_save_data($image->data);
      $file->status = FALSE;
      $account->picture = $file;
      user_save($account);
    }
  }
}

Still to do:

  • Show pictures on comments.
  • Import pictures from other Drupal.org sites.
  • Set up syncing across sites, so Drupal.org will never ask you to upload another picture.
mgifford’s picture

Great to see my photo from https://austin2014.drupal.org/users/mgifford

Now show up https://drupal.org/user/27930

Are we going to have new issues for the pictures on comments? The other two I can see as being related.

  • Commit 1b958c8 on 7.x-3.x by drumm:
    #957320 Include user picture URLs in bakery-transmitted data.
    

  • Commit 0bdadb0 on 7.x-3.x, 7.x-3.x-dev by drumm:
    #957320 Enable the support for user profile pictures
    
  • Commit 1b958c8 on 7.x-3.x, 7.x-3.x-dev by drumm:
    #957320 Include user picture URLs in bakery-transmitted data.
    

  • Commit 93dfae1 on 7.x-3.x by drumm:
    #957320 Show user pictures on comments
    

  • Commit 32f1e6e on 7.x-3.x by drumm:
    #957320 Work around picture inconsistency.
    

  • Commit 7e81ea9 on 7.x-3.x by drumm:
    #957320 Fix last commit.
    

  • Commit a32a45e on 7.x-3.x by drumm:
    #957320 Fix last commit.
    

  • Commit 3eac810 on 7.x-3.x by drumm:
    #957320 Fix features export.
    
drumm’s picture

Status: Active » Fixed
Issue tags: +needs drupal.org deployment

This is now on staging sites, like https://staging.devdrupal.org/node/2224917, for testing.

markcarver’s picture

Status: Fixed » Needs work

Looks good, just curious why we aren't cropping to a square image though (as per my design concept). This helps keep vertical space to a minimum (see the one line comments).

tvn’s picture

Can we also add default userpic for people who don't have any. There is one in Bluecheese's images folder.

markcarver’s picture

Ah, they are a max-height of 40px:

.comment .picture img {
  max-height: 40px;
}

This really throws off consistency though, an added crop would rectify this.

  • Commit 6a0bfc9 on 7.x-3.x by drumm:
    #957320 Square off user pictures.
    
markcarver’s picture

  • Commit 45f6e4b on 7.x-3.x by drumm:
    #957320 Use default user picture in comments.
    
drumm’s picture

Status: Needs work » Fixed

User pictures are now squared off and there is a default picture.

markcarver’s picture

Awesome! Thanks @drumm.

I was having an issue with that link caching the images I saw before (it's possibly behind a CDN now? not sure)

https://git7site.devdrupal.org/node/2224917 shows up just fine though.

drumm’s picture

Now deployed.

Gaelan’s picture

Horray!

webchick’s picture

Wow, this change actually looks really hot. Thanks so much for everyone's work on this!! Yay for no longer being anonymous blue nicknames. :)

chx’s picture

Very very quietly, just because I am that guy: I remember a time when being anonymous blue nicknames were considered an advantage -- being equal in gender, age and who knows what else. Now there's an actual pressure to de-anonymize yourself.

Jeff Burnz’s picture

Now there's an actual pressure to de-anonymize yourself...

Indeed.

chx’s picture

When we had a brief discussion of this on IRC someone:

I already got an email saying my icon was "cute" :(

markcarver’s picture

A user picture is completely optional. No one is being "pressured". If you wish to remain "anonymized" then don't upload a picture (or remove it).

chx’s picture

"Why you don't have an avatar?" even if not explicitly asked the pressure is present.

webchick’s picture

Avatars also pressure people to behave more like human beings. It's much easier to treat de-humanized little blue names like garbage, and much harder when you see the cute picture of their adorable cat.

So given that people can easily upload avatars that simply say "I don't need no steeeenkin' avatar!" (in tiny, tiny font) I think the pressure some might feel is an acceptable trade-off for the benefits we gain community-wise.

killes@www.drop.org’s picture

Avatars also pressure people to behave more like human beings. It's much easier to treat de-humanized little blue names like garbage, and much harder when you see the cute picture of their adorable cat.

Hmm, I've put the avatars into my blocklist as I regard them as visual clutter. Guess that surprises nobody. :D

LewisNyman’s picture

Status: Fixed » Needs work

Thanks for the work on this, I like it!

I've also noticed that we aren't using image styles correctly for these comments. The images are around 512px * 512px and they are getting resized in CSS down to 40 * 40!

That's a lot of additional kilobytes, especially on those mega issues with hundreds of comments. They were hard enough to load on a mobile phone as it was. Does it make sense to fix it here? Feels pretty major.

Thanks again.

markcarver’s picture

Not sure where you got the 512x512 dimensions. The issue comments are currently using the drupalorg_user_picture image style, which scales and crops them down to 80x80.

@drumm has mentioned that we may need to create/rename the image style for CDN/varnish cache busting, but that seems to have worked itself out.

I agree that we should be using 40x40 in the image style that's used on comments, there's no need to go larger. I'll comment on the parent issue (where the CSS changes need to be taken out). It may have just been an oversight due to complications with the images being cached while testing this.

LewisNyman’s picture

Ah I did take a screenshot, I just forgot to upload it. Is this just a caching problem?

Dave Reid’s picture

I'm definitely still seeing user pictures as large versions getting scaled down with CSS, even on this issue right now.
300x300: https://drupal.org/files/styles/drupalorg_user_picture/public/user-pictu...
512x510: https://drupal.org/files/styles/drupalorg_user_picture/public/user-pictu...

drumm’s picture

Status: Needs work » Fixed

The pictures are 80x80 for high-resolution devices. (Using the new picture element would be cool, but extra work and the 80x80 images are already relatively small.)

I corrected these by running:

$path = '/var/www/drupal.org/htdocs/files/styles/drupalorg_user_picture/public/user-pictures';
$d = dir($path);
while (FALSE !== ($entry = $d->read())) {
  list($width, $height) = getimagesize($path . '/' . $entry);
  if ($width > 80 || $height > 80) {
    preg_match('#-(\d+)-#', $entry, $match);
    list(, $uid) = $match;
    $account = user_load($uid);
    $derivative_uri = image_style_path('drupalorg_user_picture', $account->picture->uri);
    file_unmanaged_delete($derivative_uri);
    image_style_create_derivative(image_style_load('drupalorg_user_picture'), $account->picture->uri, $derivative_uri);
  }
}
$d->close();

Either some code I wrote for migrations from DrupalCon sites was calling image_style_create_derivative() incorrectly and/or the image preset cache was temporarily incorrect. When either happens, the original image gets copied over.

markcarver’s picture

Thanks @drumm! FWIW, a Shift-Refresh worked this time.

Crell’s picture

The humanizing effect of having pictures is legit. However, there is definitely pressure to have an icon. I got crap from all kinds of people for YEARS for not having a non-egg picture on Twitter. (And I'm not someone who has any reason to not have my picture and name associated.) That did stop when I switched to the Garfield icon, which looks nothing like me aside from the vest.

So, yeah. It's a trade-off. I don't know which way it will go at this point. I guess we'll find out.

One problem: I am fine with my picture on DrupalCon sites, but I'm sorely tempted to remove it from d.o. I haven't checked to see if that's possible yet.

silverwing’s picture

wondering if we should have a selection of generic drupal-related icons users can choose from...

mgifford’s picture

@silverwing can we spin that off into a follow-up issue? There are so many drupal icon variations to draw on. Would be a great wealth of goofy icons we should already be able to draw on.

Also, you'd suggested on Twitter, "Now the user System Message needs a kick ass icon!" - Agreed!

@Crell Definitely agree that this should be possible. Not everyone wants their photo used everywhere. We can't all use a great Garfield icon.

Mind you they seem different in GDO so maybe it was just pulled once with Austin to ensure that there was a solid seeding of icons going forward.

@killes@www.drop.org No harm in that. At one point we might want to offer this as an option in the user profiles. Your solution is easier though.

I am a bit confused why this hasn't been a problem on GDO... Or maybe it has, but not sure where that thread would be.

Gaelan’s picture

I think that some sort of identicon-thing would be a big improvement over a gray silhouette.

silverwing’s picture

created #2276087: Allow for a selection of user avatars

Also had #2275911: Give System User its own user picture which was shot down - if System Message isn't going to have its user name linked in issues, then there's no reason to visit its page. :(

Jeff Burnz’s picture

Avatars also pressure people to behave more like human beings.

Not that I've witnessed in any social network, e.g. Youtube.

In any case it is visual clutter and not needed in issues, I have removed them using QuickStyle.

drumm’s picture

Re removing pictures migrated from DrupalCon sites: sure, go ahead and remove / change if you want. The basic picture uploading is basic Drupal core.

I didn't migrate pictures from groups.drupal.org because they are only 85x85. Our max is now 1024x1024, hopefully enough pixels for various sizes we want for a few years. Scaling to 80x80 used on comments wouldn't be ideal. And syncing back to groups.drupal.org will be harder since it is on D6.

mgifford’s picture

@drumm - I hadn't understood that anyone wanted to roll back the image import you'd done.

I think there was uncertainty about whether the images on d.o were synced with *.d.o images. From what I understand this was only done once to seed the issue queues, so no problem. If @Crell's able to throw up Garfield here & his photos on the DrupalCon sites I think that would address his concerns.

Maybe at some point we could facilitate a way to either push out new photos when they are changed on drupal.org, but that definitely should be a new issue.

There's been lots of positive feedback from folks about this move (especially on twitter). It will be interesting to try to figure out what the impact of it is in 3 months time. Not sure how to isolate this change from it's environment. Without A/B testing infrastructure in place it is really hard to know.

Btw, I posted this blog post looking at this issue as well as the past/future ideas for shaping community involvement https://openconcept.ca/blog/mgifford/building-community-drupalorg

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

YesCT’s picture