Opened 14 years ago
Last modified 13 months ago
#16020 accepted feature request
Upload custom avatar for user in Dashboard
Reported by: | computerwiz908 | Owned by: | whyisjake |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | minor | Version: | |
Component: | Users | Keywords: | has-patch needs-refresh has-screenshots |
Focuses: | ui, administration, privacy | Cc: |
Description (last modified by )
It would be nice to be able to upload a custom avatar for a user in the WordPress Dashboard rather than making each user sign up for a Gravatar account and upload the image to that account.
Attachments (26)
Change History (164)
#8
@
12 years ago
Relevant plugin: http://wordpress.org/extend/plugins/simple-local-avatars/
#10
@
12 years ago
attachment:16020.diff adds support for self-hosted custom avatars. Users are able to:
- upload a new avatar image;
- choose a rating for their custom avatar;
- remove their current avatar image.
Users can switch between their custom avatar or their Gravatar by choosing back the Default option from the Profile page.
This patch works properly with JavaScript disabled too. The output can be previewed here: attachment:16020-profile-avatar-default.jpg, attachment:16020-profile-avatar-custom.jpg, attachment:16020-options-discussion-avatars.jpg.
#11
follow-up:
↓ 12
@
12 years ago
The patch also seems to allow custom avatar sizes.
I think the "Default" label is kind of confusing. Instead of this:
[ ] Default [ ] Custom Use Default to display your Gravatar. <a href="...">More Information</a>
we could have this:
[ ] Gravatar <a href="...">More Information</a> [ ] Custom
Otherwise, the patch looks good. There's not much point using Thickbox instead of a simple file input here.
#12
in reply to:
↑ 11
@
12 years ago
Replying to scribu:
I think the "Default" label is kind of confusing.
Agreed. I have updated the patch as you suggested.
#13
follow-up:
↓ 14
@
12 years ago
There are some inconsistencies here:
153 $user->avatar_type = 'gravatar'; 154 $user->custom_avatar = array(); 155 $user->custom_avatar_rating = 'G';
First, you allow the user to upload multiple custom avatars, but he can only set one custom_avatar_rating. I think it's best to only allow a single custom avatar.
Also, why is $user->has_custom_avatar = 'false';
set to the string 'false' rather than to the boolean false.
#14
in reply to:
↑ 13
@
12 years ago
Replying to scribu:
First, you allow the user to upload multiple custom avatars, but he can only set one custom_avatar_rating. I think it's best to only allow a single custom avatar.
The user can upload only one custom avatar. Uploading another will replace the current one. The custom_avatar array contains the same avatar, but different sizes.
Also, why is
$user->has_custom_avatar = 'false';
set to the string 'false' rather than to the boolean false.
Sorry for that. Fixed it.
#15
follow-up:
↓ 16
@
12 years ago
The custom_avatar array contains the same avatar, but different sizes.
Oh, I see.
Ideally, you should only need to store an attachment id, which could contain arbitrary sizes. See #15311
#16
in reply to:
↑ 15
@
12 years ago
Replying to scribu:
Ideally, you should only need to store an attachment id, which could contain arbitrary sizes. See #15311
To use the suggested method an avatar should be inserted as an attachment which is not the case. Making the avatars visible in Media Library would let other users to alter not only their avatar.
#17
follow-up:
↓ 18
@
12 years ago
Please don't overwrite patches that have been reviewed.
Making the avatars visible in Media Library would let other users to alter not only their avatar.
Non-administrators can only edit their own attachments.
#18
in reply to:
↑ 17
@
12 years ago
Replying to scribu:
Non-administrators can only edit their own attachments.
And users without the capability to upload files to Media Library (like Subscribers) wouldn't be able to upload an avatar image then. Should the subscribers be limited on using Gravatar only?
#21
in reply to:
↑ 19
@
12 years ago
Replying to scribu:
I think that's acceptable, as a first pass of this feature.
I've made some updates based on your feedback. Please check: attachment:16020.2.diff.
#22
follow-up:
↓ 23
@
12 years ago
The avatar cleanup code is repeated in 3 places. Should make a helper function.
#23
in reply to:
↑ 22
@
12 years ago
Replying to scribu:
The avatar cleanup code is repeated in 3 places. Should make a helper function.
Cleaned up the previous submission. Please check: attachment:16020.3.diff.
With the current patch users have only one option: to upload a new avatar image. What do you think about adding support for choosing an existing image from Media Library?
#24
@
12 years ago
I don't think it's a good idea to try something like that right now, given #21390.
16020.3.diff looks good, and works too.
Regarding UX, if a user makes some other changes to their profile, when they press the Upload button they'll loose their changes, right?
#25
@
12 years ago
Nevermind, they won't.
The "Remove Image" button should be to the right of the Custom option, not below the rating and should probably be red and say "Delete".
#26
follow-up:
↓ 27
@
12 years ago
Oh, if you have a custom avatar and you go to /author/your-user/ in the front-end, using the Twentyeleven theme, you'll see the gravatar instead.
#27
in reply to:
↑ 26
@
12 years ago
Replying to scribu:
The "Remove Image" button should be to the right of the Custom option, not below the rating and should probably be red and say "Delete".
Tried to keep the interface consistent (take a look at Appearance > Header / Background). If it's not the case, I'll follow your suggestion.
Oh, if you have a custom avatar and you go to /author/your-user/ in the front-end, using the Twentyeleven theme, you'll see the gravatar instead.
Sorry for that. Fixed it in: attachment:16020.4.diff.
Thank you for your help!
#28
follow-up:
↓ 29
@
12 years ago
Tried to keep the interface consistent (take a look at Appearance > Header / Background).
It's not the same. The header takes up the whole width.
Also, that whole page is dedicated to the header, whereas on the profile page you have all sort of other things going on, so compactness is more important.
#29
in reply to:
↑ 28
@
12 years ago
I've updated the "Delete" link. Please check: attachment:16020.5.diff and attachment:16020.5-profile-avatar-custom.jpg for preview.
#31
follow-up:
↓ 32
@
12 years ago
To me, this interface is confusing.
What is the 'Select Image' field for? Is this my avatar? Is this a fallback avatar for users without avatars? Is it a global avatar for all users?If I switch between Gravatar and Custom (and vice versa), the explanatory text for Avatar Rating is no longer accurate.It's not clear that the Remove Avatar Image button applies only to your custom avatar.
Okay I should have actually applied the patch instead of going by screenshots. This is the user profile screen, not the avatar section of the Discussion Settings screen.
I still think it's a little unclear that the Avatar Rating and Remove Image controls only apply to your custom avatar. This needs to be made clearer.
#32
in reply to:
↑ 31
@
12 years ago
Replying to johnbillion:
I still think it's a little unclear that the Avatar Rating and Remove Image controls only apply to your custom avatar. This needs to be made clearer.
The "Avatar Rating" controls becomes visible only when the user have a custom avatar uploaded. Also, the "Remove Image" section is not anymore there. It was replaced with the "Delete" link in the latest version of the patch (attachment:16020.5.diff) as you can see in: attachment:16020.5-profile-avatar-custom.jpg.
Thank you for your feedback and for testing the patch.
#33
@
12 years ago
attachment:16020.6.diff updates the previous submission making the patch ready to test against the latest revision (23184). Going to use the new wp_get_image_editor() instead of the deprecated image_resize() to get rid of the notices.
I want to add support for the new media manager but I think it would be better to wait until the ticket gets closed. Because the code is getting pretty big for a single patch I suggest to continue it separately. It would be easier to write (and review) and to avoid creating new bugs.
#34
@
12 years ago
- Keywords close added
- Owner set to nacin
- Status changed from new to reviewing
I don't think this is core material. Gravatar, despite it being "a private, hosted third-party service," is the industry standard. Suggesting close as maybelater, or wontfix.
#35
follow-up:
↓ 38
@
12 years ago
Erm, no; the industry standard is for each site to have their own user avatars. See twitter, facebook, etc. etc.
#37
follow-up:
↓ 45
@
12 years ago
I agree with jane and scribu. Even if it's not an important feature it's requested by users (Add Local Avatar has reached more than 250K downloads and it's just one of the available plugins). Gravatar will be still the default option even if support for self-hosted avatars is added. I think it's better to have this option rather than making users to register an alternate email address on Gravatar or install an additional plugin.
#38
in reply to:
↑ 35
;
follow-up:
↓ 39
@
12 years ago
Replying to scribu:
Erm, no; the industry standard is for each site to have their own user avatars. See twitter, facebook, etc. etc.
-1, I agree with nacin. I personally think this is firmly plugin territory.
The examples you noted are social networks, so they have their own avatars, whereas most other sites don't. See GitHub (which is basically a social network), StackOverflow (ditto), etc. (Note that these are technology-focussed sites, so that's slightly biased.)
#39
in reply to:
↑ 38
@
12 years ago
Replying to rmccue:
The examples you noted are social networks, so they have their own avatars, whereas most other sites don't. See GitHub (which is basically a social network), StackOverflow (ditto), etc. (Note that these are technology-focussed sites, so that's slightly biased.)
The Envato marketplaces (ThemeForest, CodeCanyon etc.) are technology-focused sites too and they don't have support for Gravatar.
Thinking again the situation. Mixing both options (Gravatar and self-hosted avatars) doesn't seem right for core. Obviously, replacing Gravatar is not a good choice either. Perhaps moving it into a separate plugin would be the most appropriate solution.
Closing it as wontfix would be fine for me. But let's wait for nacin and scribu to confirm and take a decision.
#40
follow-up:
↓ 41
@
12 years ago
Maybe a better course of action would be to lobby the Gravatar developers (i.e. Automattic?) to release some sort of API which opens an iframe/lightbox/whatever for users to create/change their image, instead of having to go to Gravatar.com to do it, which is quite a confusing workflow.
#41
in reply to:
↑ 40
;
follow-up:
↓ 42
@
12 years ago
- Cc beau@… added
Replying to scribu:
Maybe a better course of action would be to lobby the Gravatar developers (i.e. Automattic?) to release some sort of API which opens an iframe/lightbox/whatever for users to create/change their image, instead of having to go to Gravatar.com to do it, which is quite a confusing workflow.
You could load gravatar.com in a thickboxed iframe right now, we actually do something like that on WordPress.com. Signup would still be an issue though (and there are no plans to provide a signup API). Because we need to verify ownership of an email address before we can assign it to an account, there needs to be some involvement with Gravatar.com there.
We've talked about possibly making the signup flow easier to integrate with other (non-Gravatar) sites, but haven't come up with a good solution to that yet that still includes the verification step.
As a sidenote, you can link here to slightly improve the signup process: https://gravatar.com/site/signup/email%40domain.com
And check if a user has an existing Gravatar by requesting this, with the 0's replaced with the user's email hash: http://www.gravatar.com/avatar/00000000000000000000000000000000?d=404 (default = 404 response)
There is also an XMLRPC API for working with Gravatar, although to be honest it doesn't get much attention since I don't believe many folks use it. Obviously that would change if WP core started using it. http://en.gravatar.com/site/implement/xmlrpc/
#42
in reply to:
↑ 41
@
12 years ago
Replying to beaulebens:
There is also an XMLRPC API for working with Gravatar, although to be honest it doesn't get much attention since I don't believe many folks use it. Obviously that would change if WP core started using it. http://en.gravatar.com/site/implement/xmlrpc/
Thank you for the information. I think it's a good approach to let users manage their Gravatar right from the profile screen. It would improve the workflow making it less confusing. Going to take a more in-depth look at the XMLRPC API to see what it can be done.
I've moved the current patch into a plugin, cleaned it up and documented the code. It's available on GitHub and WordPress Plugin Directory if anyone is interested in giving some help or just prefers a plugin to work with than hacking directly the core.
#43
follow-up:
↓ 46
@
10 years ago
I've been actively maintaining the plugin since I released it, about 2 years ago. I still think a solution should be considered for core. It was suggested by many and it's a pretty requested feature. I don't say that's the only way to do it; there are also a few other great plugins: Simple Local Avatars, WP User Avatar and Add Local Avatar, although some of them may be a bit too much for core. Just to be clear, the proposed solution doesn't remove Gravatar support or break backward compatibility.
rmccue mentioned GitHub and Stack Overflow as a counterargument. Less than a month later, Stack Exchange announced a new way to change profile pictures for the entire network (including Stack Overflow). So anyone who wants to use a custom picture is able to simply upload one or to switch back to their Gravatar. Last year, GitHub did the same announcing that switching profile pictures just got easier.
WordPress has evolved from just a blogging platform to a full CMS. Basically you can use if for almost anything; is Gravatar alone a satisfying solution? While it may be a perfect fit for blogs, I don't think it's enough for sites with lots of registered users (universities, organizations, eCommerce stores or any kind of communities). Built-in profile pictures could be also a nice addition even for bbPress and BuddyPress.
So what do you think? It would be great to see more opinions on this and get some traction, eventually.
This ticket was mentioned in Slack in #core by helen. View the logs.
10 years ago
#45
in reply to:
↑ 37
@
10 years ago
The idea of having an external site that a self-hosted site depends on bothers me on some level, even if it is gravatar. I don't think it should come out, but I think it is important that WordPress out of the box should allow for not using it by having a default avatar as part of core and the option to add local ones.
Replying to cdog:
I agree with jane and scribu. Even if it's not an important feature it's requested by users (Add Local Avatar has reached more than 250K downloads and it's just one of the available plugins). Gravatar will be still the default option even if support for self-hosted avatars is added. I think it's better to have this option rather than making users to register an alternate email address on Gravatar or install an additional plugin.
#46
in reply to:
↑ 43
@
10 years ago
I agree that local avatar support should be considered for core. Gravatar’s been in wordpress for a long time, and likely has to stay in core for the sake of the sites already out there using it… but open source blogging software should not depend on a particular cloud service for any of its core functionality.
Gravatar is so entwined in wordpress that the codex describes avatars as something inherently cloud-based (“an image that follows you from weblog to weblog”). Integrating it into core w/ 2.5 was probably a mistake.
This is a minor, but real, problem that should be addressed.
Replying to cdog:
So what do you think? It would be great to see more opinions on this and get some traction, eventually.
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
10 years ago
#49
@
9 years ago
Would be nice to see this implemented, several years after the ticket being opened and still it isn't in core. Uploading your own avatar is very basic functionality.
#50
@
8 years ago
Its very necessary to change gravatar from admin panel. I hope it will be added soon in core.
#51
@
8 years ago
+1 For getting this added to core.
It's not a great UX to only allow profile images from Gravatar. There should definitely be a core option to specify a local avatar too.
#52
@
8 years ago
I see this haven't got so far and it's neither rejected or closed as wontfix. I'm curious if there's any interest from the core team to support this. Maybe the approach isn't right just yet?
Here's what I'm thinking. I would swap Gravatar with self-hosted avatars in core and move Gravatar to an official plugin (just like Akismet). And ship it with WordPress already preactivated. Users (and admins/site builders) would be able to choose the preferred method. How does this sound? Are there any negative impacts that would affect WordPress or Gravatar by any means?
#53
@
8 years ago
@cdog I agree with you in principle. But I think implementing local avatars is necessary before you discuss removing gravatar and that local avatars should be used before remote services. But it would break sites to remove it if the plugin you propose is not enabled by default.
#54
@
8 years ago
I wonder why this is still a ticket for 4 years now. This should be definitely in core for a number of reasons:
- WordPress attracts also non-geeks - not everyone has a Gravatar Account
- Not everyone wants to display the same Gravatar on every connected service - some just want different avatars for different sites
- Local avatars can be changed more easily and faster
- It just don't feel right to make users dependent on a third-party service - Gravatar support as a fallback might be the better idea
#55
@
8 years ago
I suggest refreshing the patch to take advantage of changes in WordPress over the last four years and tag it for early review in 4.8.
This ticket was mentioned in Slack in #core-media by paaljoachim. View the logs.
8 years ago
#58
@
8 years ago
People behind bbPress and BuddyPress would be thankful too.
It is like playing chess, use all those and guess what avatar is used where, and what to use of custom snippets to override where.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
7 years ago
#61
@
7 years ago
Wow! I've just realised there's no sane way to get custom avatars working in WordPress, other than using some hack-around plugins... That's rather sad, as not all clients are happy to create another account somewhere else just to get their profile picture working.
Aso, claiming "our product is an industry standard, and that's it" doesn't sound that open-sourcey...
This ticket was mentioned in Slack in #core by selrond. View the logs.
6 years ago
#65
@
6 years ago
Adding here since #46084 was closed as duplicate:
To add a user profile photo to a WordPress site without adding a plugin, the user has to create a Gravatar. Creating a Gravatar requires a WordPress.com account. This requires the user of a self-hosted WordPress site to have a WordPress.com account to use a core feature.
Gravatar is a great idea and a great service. However, having a WordPress.com account should not be a prerequisite to use a core feature, especially something as central and expected as a user profile photo. In my opinion.
Having Gravatar be the only core option for user profile pictures introduces several issues including (but not limited to):
- Having to have a WordPress.com account.
- No access to WordPress.com or Gravatar.com from intranets and systems not connected to the web or behind firewalls or geoblockers that block either domain.
- Data collection and privacy concerns (real and/or imagined) around what it means to upload a photo to Gravatar.com / create an account on WordPress.com. (see #45384 as example)
## Proposal
- Introduce a core option to use profile photo from media library.
- Sunset Gravatar as core option. Offer Gravatar as plugin.
- Introduce Gravatar-type service not tied to WordPress.com (ideally hosted by WordPress.org or similar).
This ticket was mentioned in Slack in #core-privacy by desrosj. View the logs.
6 years ago
#67
@
6 years ago
- Keywords needs-design-feedback added; ux-feedback removed
I am just swapping the keyword to 'needs design feedback', which is being used now for design feedback.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
5 years ago
This ticket was mentioned in Slack in #design by estelaris. View the logs.
5 years ago
#70
@
5 years ago
- Keywords needs-design-feedback removed
Removing the needs-design-feedback
keyword as part of the design team's triage. Please feel free to add it back if this ticket is refreshed.
#71
@
5 years ago
I agree very much on Morten's @mor10 comments!
--
It is time to get a core selection of the local avatar one wants to use in place. Comments further above here in this ticket mentioned only social sites to where one could choose an avatar. Today a lot of sites have a simple way to add a local avatar to ones own profile.
Let's get this in.
@cdog Could you re-create/update the patch you once make so we can continue the process of getting this into Core? Possibly for 5.5. Thanks!
This ticket was mentioned in Slack in #core-media by paaljoachim. View the logs.
5 years ago
#73
@
5 years ago
Any updates here? Could refresh/rework the patch if there’s interest in getting this to core.
This ticket was mentioned in Slack in #core-privacy by sephsekla. View the logs.
5 years ago
#76
@
5 years ago
I think this could use some input from a maintainer of the Users component. @johnbillion if you don't mind the ping, I'm curious your thoughts on getting this in the scope of 5.5. There's a lot of history here that I want to be mindful of. I personally think that this is a great change and our gracious contributor @cdog has offered to refresh.
This ticket was mentioned in Slack in #core-themes by paaljoachim. View the logs.
5 years ago
#80
@
5 years ago
- Keywords 2nd-opinion removed
I'd really like to see this in core too. Many clients I work with find it confusing that they can't change their user profile image without signing up to an external service, and clients in some countries such as Germany just flat out refuse to use Gravatar due to privacy and data protection considerations.
Gravatar certainly has its use, and I very much enjoy not having to re-upload an avatar image on every other web service I use, but there's really no reason for core to rely solely on Gravatar and not provide local avatar image functionality.
The patches on this ticket are quite old and there are many plugins that provide user avatar functionality that allows a local avatar to override a Gravatar, with the latter remaining the default for backwards compatibility. Is anyone willing to start listing some high quality plugins that could be a good basis for inclusion in core?
Ideally the avatar image control would make use of the image cropping controls that are available in the media manager (as used by the favicon, site icon, etc).
#82
follow-up:
↓ 83
@
5 years ago
Hi everyone, thanks for commenting recently.
@johnbillion been maintaining the old patch as a plugin. Can start looking from there, plus some others. My personal candidates are:
- Avatar Manager, https://wordpress.org/plugins/avatar-manager/
- Simple Local Avatars, https://wordpress.org/plugins/simple-local-avatars/
- WP User Avatar, https://wordpress.org/plugins/wp-user-avatar/
Please take a look at above list, anyone please suggest more options as needed. I find first two more suitable for Core due to their simplicity. Further enhancements can be added, wouldn't limit to exactly what these plugins do or look - feel free to come up with ideas and propose some requirements.
Cropping certainly can be added if not already there. Should also discuss briefly overall design. Most of available plugins bypass certain roles and capabilities (like Subscriber, or Contributor) to allow uploading their own images while still handled via Media Library.
Open for discussion and more than excited to help further. Thank you!
#83
in reply to:
↑ 82
@
5 years ago
Replying to cdog:
I would add this one to the list:
- User Profile Picture, https://wordpress.org/plugins/metronet-profile-picture/
Really simple and easy.
#84
@
5 years ago
The above shows various profile screens from the plugin name mentioned.
I made a mockup based on the above. Here is one with rating included.
This ticket was mentioned in Slack in #design by paaljoachim. View the logs.
5 years ago
#86
@
5 years ago
Thanks to @paaljoachim for creating great mockups.
I think the solution for adding a custom profile picture should be iterated.
Firstly, it should be a radio input for choosing between Gravatar or custom from Media Library. For custom picture, we can display only 1 selected image from Media Library and borrow the UI pattern from the Media Library.
#87
@
5 years ago
The two mockups above shows an even closer representation to what this feature might look like in the profile screen.
Clicking the Media Library radio button it would start out with a placeholder picture. The user clicks the Media Library button and adds the profile picture they want to use.
This ticket was mentioned in Slack in #meta by paaljoachim. View the logs.
5 years ago
This ticket was mentioned in Slack in #design by paaljoachim. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-editor by paaljoachim. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
4 years ago
#93
@
4 years ago
With two of the previously referenced plugins on this ticket still being supported, why not close this as wontfix given there's immediate assistance for anyone who wants a non-Gravatar avatar?
Disclaimer: I work at 10up and help maintain the Simple Local Avatars plugin.
#94
@
4 years ago
I think the fact that there are so many plugins that do this highlights why this should be fixed @JeffPaul, many people want it, and loads that would want it don’t even realize it’s an option they could install a plugin for.
#95
@
4 years ago
Agree with @joostdevalk point.
I think the fact that there are so many plugins that do this highlights why this should be fixed @JeffPaul, many people want it, and loads that would want it don’t even realize it’s an option they could install a plugin for.
Additionally:
- I feel it's inappropriate to force a proprietary service registration; data has value.. It makes Automattic subject to the appearance of a conflict of interest, that alone is a reason not to, especially since it's a wanted feature.
- Additionally, it's a hassle for sites with thousands of users who are all potentially forced through this hoop.
#96
@
4 years ago
I spoke with Joen over Slack to get some input on the mockups. He suggested the very simple method of just changing the sentence and add a link to "Gravatar" and a link to "upload an image."
This should be a very easy fix that also leaves a very small footprint.
#98
in reply to:
↑ 97
@
4 years ago
Replying to joostdevalk:
I'm all for that :) Who can make that happen? :)
@cdog will be able to create a patch.
https://core.trac.wordpress.org/ticket/16020#comment:73
"Any updates here? Could refresh/rework the patch if there’s interest in getting this to core."
#99
@
4 years ago
- Focuses ui administration privacy added
- Keywords has-screenshots added
Love to see some activity here, thank you all. This has been a longstanding item on the Core-Privacy roadmap;
Gravatar Privacy Controls
Site owners and users should have greater control over integrations with Gravatar. Gravatars can potentially expose user activity across the web. Hashes can be subject to brute force attacks to reveal the user’s email address or can be found in rainbow tables, exposing the user’s identity.
Related tickets: #16020, #44067, #14682
I'll drop a note in our weds 19:00UTC office hours as I'm sure there's plenty of people interested in helping here, and feel free to use the #core-privacy channel if you need an avenue to discuss development.
#100
@
4 years ago
Drafted a new version based on recent feedback. Love the ideas, especially Joen's proposal - its simplicity feels so native. Also added cropping controls as @johnbillion suggested.
Check above recording, or try it yourself by applying the patch. This is proof of concept, please take it as such - refactored patch will come as we progress.
This needs upload_files capability to get enabled. Users without this permission will only see Gravatar message (i.e. subscribers). As next steps would discuss any enhancements, compatibility with existing plugins, and the items suggested by @garrett-eclipse from Core Privacy roadmap.
Eager to receive your feedback :-)
This ticket was mentioned in Slack in #core-privacy by paaljoachim. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-privacy by garrett-eclipse. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
4 years ago
#104
@
4 years ago
One thing we'll want to make sure is considered and tested is how this works in multisite. Is a users avatar that's uploaded to one site replicated across others they're on? Do they have to upload the same avatar to each site if that's what they want? Does updating an avatar on one site ensure others remain the same for that user or do they all get updated to the newly updated avatar?
This ticket was mentioned in Slack in #core-multisite by paaljoachim. View the logs.
4 years ago
#106
@
4 years ago
Just dropping this in here quickly before I set off for the night.
I have a plugin that explores a lot of these ideas and functionality fully:
https://wordpress.org/plugins/wp-user-avatars/
Happy to sit in on a meeting anytime to chat more.
This ticket was mentioned in Slack in #core-media by paaljoachim. View the logs.
4 years ago
#108
follow-up:
↓ 110
@
4 years ago
Tomorrow (Thursday) is the weekly Core Media Chat Meeting at
04:00 PM GMT+2 (Check your local time) https://www.timeanddate.com/worldclock/fixedtime.html?msg=Core+Media+Meeting&iso=20200618T10&p1=2157&ah=1.
We will be discussing the custom avatar feature. Do please join us in the #core-media Slack channel https://wordpress.slack.com/archives/C02SX62S6.
Agenda: https://make.wordpress.org/core/2020/06/18/media-chat-agenda-18th-june-2020/
This ticket was mentioned in Slack in #core by peterwilsoncc. View the logs.
4 years ago
#110
in reply to:
↑ 108
@
4 years ago
@JeffPaul thanks for pointing that out, multisite it's something that should be discussed.
@paaljoachim Having following items would like to address:
- Feature design and complexity - what fits for core vs plugin material
- Compatibility with existing plugins - I think plugins should still be able to extend/override avatar functionality cc @JeffPaul
- Items tracked in Core-Privacy roadmap - should be tackled as part of 16020 or can be addressed later in their own respective tickets?
Feel free to edit above list. On feature design, seeing at least the following:
- Ability to browse media or upload image as profile picture
- Restricted to users without upload_files capability - i.e. subscribers won't be allowed to upload own profile picture, this can be covered by plugins
- Uploaded images will appear in Media labeled as Profile Picture
- Cropping and on-demand image size generation
- Multisite support - this can be achieved in a number of ways
- Unsetting/removing a profile picture
- Option to turn avatars off and completely disable the feature cc @dshanske
Also please check recent demo attachment:16020-demo.mp4 if you didn't already. Thanks and see you in the Core Media Chat Meeting.
#111
@
4 years ago
There are two levels of disabling...per user or global. I think if disabled globally, we just don't show any avatar options on the user profile. But if a user sets no avatar, maybe deliver a mystery man(the default gravatar icon) stored locally and we can add a filter for plugins to enhance that.
The user feature should be built into Core. With the global feature, the question is of it is a filter that a plugin could activate or a new setting. I tend to lean toward filter and let someone add a disable all avatar or all gravatar plugin, as long as we have the filters set up. That should satisfy the privacy concerns.
For me, I like avatars, but I don't feel I need gravatar to serve my image on my own site.
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
4 years ago
#113
@
4 years ago
Following on from today's discussion in #core-media (linked above), here's a collaborative research and planning spreadsheet for collecting requirements and investigating functionality in existing plugins: https://docs.google.com/spreadsheets/d/172jXhfzVFfKfk8M4NXa3e29GlQhZpAaWSxZCrH07_fo/edit#gid=0
Feel free to fill out details.
#114
@
4 years ago
Good for WP comments. Still needs for Subscribers Role too.
BuddyPress has it made well.
#115
@
4 years ago
That looks great!
Please add the "No picture" option for everyone, but it would especially benefit subscribers / those without rights.
Also, it would be nice to have the ability for admins to add a predefined option(s), but that is a nice-to-have :)
#117
@
4 years ago
Love the great work that has gone into this ticket. Any ideas on how to get all of the plugins onto the same page? Would be great if this was merged into core, they would all continue to work the same.
#118
@
4 years ago
It is great with all the ideas!
But I am also noticing a higher level of complexity sneak in.
I am afraid that working through the various levels of complexity would take too much time and effort. Pushing the local avatar Core integration further into the future. We need to go back to basic and take it one tiny step at a time.
What is needed of a MVP to get this feature into WordPress Core?
We need a basic first version that can over time step by step be iterated/improved.
Thanks!
@
4 years ago
Mockup suggestion: Adding an X to go back to default WP avatar image or to use no image.
@
4 years ago
Mockup suggestion: Changing picture to image and changing the sentence to include choose to use no image.
This ticket was mentioned in Slack in #core-media by paaljoachim. View the logs.
4 years ago
#120
@
4 years ago
It's exciting to see this older ticket picking up so much steam.
Implementing user uploads and customization of local avatars introduces a lot of actual and potential complexity, and may have unintended security consequences or surface area, as we found with our comment moderation changes recently. (BuddyPress is a good example of this!) There are also easy plugin ways to change how avatars work, so we likely aren't going to have a big impact on the world or WP's adoption by bringing this into core.
From an every day usability point of view, we have some very important items on our roadmap!
Let me use this opportunity to point to our progress on the 9 projects we set out to accomplish last year: https://make.wordpress.org/core/2019/12/06/update-9-projects-for-2019/
And the scope for 5.5: https://make.wordpress.org/core/2020/05/13/wordpress-5-5-planning-roundup/
An effort I would be very interested in supporting is creating a featured plugin, like a Gutenberg for privacy, that would be de-coupled from the core release schedule and iterate on providing the most control and flexibility for site administrators to customize the privacy options on their site relevant to their audience and priorities. The privacy working group could have a lot of autonomy for choosing what to prioritize within this plugin, and we could hopefully attract a wider array of global contributors and create more collaboration on a single plugin where right now we have developers making many separate plugins to solve some of the same issues.
That discussion is out of scope for this ticket and we should continue the discussion on the relevant P2s and Slack meetings, but I just didn't want to lose the energy we have here given this particular issue isn't a good fit for 5.5.
#121
@
4 years ago
@matt, I don't hear you say any real arguments against it. Privacy is exactly an argument to give options outside the Gravatar arena, as argued. Also it's highly unpractical as is. And see all other arguments in the thread.
Personally I tried all of the plugins mentioned and none of them work consistently on my sites. This subject requires a stable core implementation.
I vote to continue.
#122
@
4 years ago
I believe Matt said this:
He is for the project but that it would not have enough time to get into 5.5. The beta is in 1.5 week. I have been hoping a while to get it into 5.5 and have probably pushed a bit to get it in. I am slowly understanding that this feature will not have time to be added to 5.5. As important aspects of this feature I knew nothing about has come up in the Google Doc shared above.
Matt is also suggesting to expand the scope to embrace additional privacy concerns. In a sense making the project a bit bigger than what I initially thought it would be.
So the bottom line is this: We now have a chance to work closer with the privacy team on integrating additional privacy concerns that are associated among other things with the local avatar. That is how I read it. I think it is a very good idea.
Moving forward. We should have a discussion about this during a privacy chat. To understand how we can incorporate better privacy controls for administrators. That sounds pretty exciting to me.
There was a core media meeting today and as we did not have time to discuss the local avatar feature. It was decided to have another chat tomorrow at the same time in the #core-media channel. We will be talking about concerns directly related to the local avatar. We can also keep in the back of our minds privacy controls for a site as well where the local avatar is one part.
This ticket was mentioned in Slack in #core-privacy by paaljoachim. View the logs.
4 years ago
#124
@
4 years ago
In #Core-privacy we are always looking at the privacy concerns of using WP and ofcourse we already have talked a lot about the various concerns with regards to the use of Gravatar. Solving this problem will not only have a positive impact on WP's adoption, but it will also make it more easy for admins to comply with privacylaws such as GDPR/CCPA/Pipeda etc. We have some great privacy ideas that hopefully will be included the 5.6 roadmap, such as the much needed Consent API , and it would be great if more Privacy related ideas such as the local avatar can be included in 5.6 as (part of ) a feature plugin.
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
4 years ago
#126
@
4 years ago
Since this has veered away from just local user uploading, I'll link to in my plugin Avatar Privacy as an existing solution for the privacy controls (regarding Gravatar). It also includes local profile picture uploads (but currently not picking from the Media Library and cropping). It does integrate with some existing "uploaded profile picture" providers.
(Oh, and hopefully I'll be notified of new posts to this ticket now. Haven't gotten any mails so far, despite "watching" the ticket since forever.)
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-privacy by sageshilling. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-media by paaljoachim. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-media by paaljoachim. View the logs.
4 years ago
#132
@
4 years ago
- Description modified (diff)
It's worth noting as we are working towards this change. Being able to pass a registered size param to get_avatar()
is desirable and maybe in the scope of this ticket?
We came across this issue in the recent Media bug scrub: https://core.trac.wordpress.org/ticket/37773
Am I wrong that the current patch is using full
by default? I'm seeing in the patch get_avatar_url
is using 'full'. Is that a risk if I have a long list of posts with folks that upload large images as their profile pictures?
This ticket was mentioned in Slack in #core-privacy by paapst. View the logs.
3 years ago
This ticket was mentioned in Slack in #core-privacy by paaljoachim. View the logs.
2 years ago
#136
@
2 years ago
Hi,
I've been looking at the following issues with gravatar being used on a WordPress site and have commented on the closed ticket #55062 ...
- The use of gravatar poses an issue with GDPR because it exposes visitor's IP addresses to a third party server without their prior consent
- The use of gravatar exposes the md5 hash of a user's email address which is insecure and poses an issue because an email address is considered to be PII, or personally identifiable information
- Users' hashed emails are exposed whether they have signed up to gravatar or not
- Visitors' browsers request a gravatar whether the gravatar exists or not
I have put together a rough solution in the form of a filter which I think solves all of these issues. The code below caches the gravatars at a server level on request and names them by user ID. Images are re-requested when they are a week old.
As far a I can see, this code only has two issues ...
1) The initial (and subsequent) caching requests are made at the time of page load which will slow down the page. This could be resolved by moving this into a CRON schedule.
2) The code requires that the users have an account. This won't work for gravatars for comments that don't have user accounts.
I'd be interested to hear what you think.
Thanks,
Oliver
<?php add_filter('get_avatar_url', 'gravatar_cache_get_avatar_url', 10, 3); function gravatar_cache_get_avatar_url($url, $id_or_email, $args) { $user = false; $mystery = false; if (is_object($id_or_email) && isset($id_or_email->comment_ID)) { $id_or_email = get_comment($id_or_email); } if (is_numeric($id_or_email)) { $user = get_user_by('id', absint($id_or_email)); } elseif (is_string($id_or_email)) { $user = get_user_by('email', $id_or_email); } elseif ($id_or_email instanceof WP_User) { $user = $id_or_email; } elseif ($id_or_email instanceof WP_Post) { $user = get_user_by('id', (int) $id_or_email->post_author); } elseif ($id_or_email instanceof WP_Comment) { if (!empty($id_or_email->user_id)) { $user = get_user_by('id', (int) $id_or_email->user_id); } if ((!$user || is_wp_error($user)) && !empty($id_or_email->comment_author_email)) { $user = get_user_by('email', $id_or_email->comment_author_email); } } $upload_dir = wp_upload_dir(); $filepath = $upload_dir['basedir'] . '/gravatar/'; if (!is_dir($filepath)) { mkdir($filepath); } if (isset($user->ID) && $user->ID && isset($user->user_email) && sanitize_email($user->user_email)) { $last_checked = absint(get_user_meta($user->ID, 'gravatar_updated', true)); $current_timestamp = time(); $avatar_filename = $user->ID . '-' . $args['size'] . '.jpeg'; $avatar_filename_png = $user->ID . '-' . $args['size'] . '.png'; if ($last_checked < ($current_timestamp - 604800)) { if (file_exists($filepath . $avatar_filename)) { unlink($filepath . $avatar_filename); } if (file_exists($filepath . $avatar_filename_png)) { unlink($filepath . $avatar_filename_png); } delete_user_meta($user->ID, 'gravatar_mystery'); update_user_meta($user->ID, 'gravatar_updated', $current_timestamp); } if (get_user_meta($user->ID, 'gravatar_mystery', true)) { $avatar_filename = 'mystery-' . $args['size'] . '.jpeg'; $avatar_filename_png = 'mystery-' . $args['size'] . '.png'; } if (file_exists($filepath . $avatar_filename)) { return $upload_dir['baseurl'] . '/gravatar/' . $avatar_filename; } if (file_exists($filepath . $avatar_filename_png)) { return $upload_dir['baseurl'] . '/gravatar/' . $avatar_filename_png; } $headers = @get_headers('https://www.gravatar.com/avatar/' . md5(strtolower(trim($user->user_email))) . '?d=404'); if (!$headers || ($headers && !preg_match("|200|", $headers[0]))) { update_user_meta($user->ID, 'gravatar_mystery', true); $avatar_filename = 'mystery-' . $args['size'] . '.jpeg'; $avatar_filename_png = 'mystery-' . $args['size'] . '.png'; if (file_exists($filepath . $avatar_filename)) { return $upload_dir['baseurl'] . '/gravatar/' . $avatar_filename; } if (file_exists($filepath . $avatar_filename_png)) { return $upload_dir['baseurl'] . '/gravatar/' . $avatar_filename_png; } } } else { $avatar_filename = 'mystery-' . $args['size'] . '.jpeg'; $avatar_filename_png = 'mystery-' . $args['size'] . '.png'; if (file_exists($filepath . $avatar_filename)) { return $upload_dir['baseurl'] . '/gravatar/' . $avatar_filename; } if (file_exists($filepath . $avatar_filename_png)) { return $upload_dir['baseurl'] . '/gravatar/' . $avatar_filename_png; } } $gravatar = wp_safe_remote_get($url); if ( isset($gravatar['body']) ) { if ('.png"' === substr($gravatar['headers']->offsetGet('content-disposition'), -5)) { $avatar_filename = $avatar_filename_png; } global $wp_filesystem; if (empty($wp_filesystem)) { require_once (ABSPATH . '/wp-admin/includes/file.php'); WP_Filesystem(); } $wp_filesystem->put_contents($filepath . $avatar_filename, $gravatar['body']); } else { $avatar_filename = 'mystery-' . $args['size'] . '.jpeg'; } return $upload_dir['baseurl'] . '/gravatar/' . $avatar_filename; }
Agreed. Requiring dependence on a private, hosted third-party service doesn't seem right.