Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default/Fallback avatar #30

Open
kraftner opened this issue Oct 24, 2016 · 1 comment
Open

Default/Fallback avatar #30

kraftner opened this issue Oct 24, 2016 · 1 comment
Assignees
Projects
Milestone

Comments

@kraftner
Copy link
Member

kraftner commented Oct 24, 2016

In contrast to default WP behaviour nothing (an empty string) is returned when the user doesn't have an avatar assigned. This means that you can't have a default avatar as the default argument of get_avatar is ignored.

There are multiple options to handle this:

1. Fall back to default behaviour (Gravatar) when no local avatar is set

This is probably expected behaviour when this plugin is seen as an extension of default WP behaviour.

2. Only fall back to default if it is a URL

This is probably expected behaviour if this plugin is seen as a replacement of default WP behaviour. Especially since one of the benefits of this plugin is/can be not to leak any information to Gravatar this should in any case be an option.


Personally I'd prefer option 2 as it is the safe default. But option 1 is probably more aligned with user expectations. A filter for this should exist in any case.

@franz-josef-kaiser
Copy link
Member

franz-josef-kaiser commented Nov 16, 2016

Totally agree. The plugin now is at a point where it needs three things (in pretty much this order):

  1. Fix the existing bugs
  2. Remove everything (files, strings) from the original plugin that is not in use
  3. Start writing up the actual user stories and things that really happen

Especially point three is what I think is important if the plugin should stay maintainable. Then decisions like this issue are much easier (with an overview of where things need to change). Also it would make it easier for other developer using this plugin when there is a written description of what use cases this plugin serves – this with a certain attention of detail is what I am often missing with other plugins and what I would like to have here in the "end" with a v1.0.0. So +1 from me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
1.0.0
Ready
Development

No branches or pull requests

2 participants