Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 6 years ago

#4237 closed enhancement (maybelater)

Adding avatar file names to db

Reported by: modemlooper's profile modemlooper Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Core Keywords: 2nd-opinion, trac-tidy-2018
Cc:

Description

This is needed for json response to allow images in applications. Ive had to do some loopy readdir to get images in external apps. if only the user meta had the file name it would be simple. I've tried a few variations of code but it requires multiple calls and it causes slow downs on loading data and this is not something people want from a native type mobile app.

Currently I call db for users, get ther ids, then read through all the avatar folders to see if image is even there then merge it all together.

Anyhoo, just adding this to get a discussion going on it.

Change History (7)

#1 @r-a-y
12 years ago

  • Keywords reporter-feedback added

Do you need the full avatar URL or just the filename?

Have you tried the following in your script?

// get the avatar URL for a user
$avatar_url = bp_core_fetch_avatar( 'html=false&item_id=' . YOUR_USER_ID_HERE );

// echo the avatar URL
echo $avatar_url;

#2 @modemlooper
12 years ago

Hey ray!

Yup, using that now but it's a slow down for an API. I have to get user ids then from those ids returned get image. If file name was included in user meta it would remove 1/3 of time for the response data. Only needs file name as I cache site/ directory urls in the app

#3 @r-a-y
12 years ago

Hmm... for your use case, I would probably cache the avatar URL when a user uploads a new avatar.

Something like:

// totally untested!
function my_cache_avatar_url() {
	update_user_meta( bp_displayed_user_id(), 'modemloopers_awesome_avatar_url', bp_core_fetch_avatar( 'html=false&item_id=' . bp_displayed_user_id() ) );
}
add_action( 'xprofile_screen_change_avatar', 'my_cache_avatar_url' );

Then you can reference the avatar URL via user meta.

The caveat here is this is done on a case-by-case basis. If you need to do this for every user (at least initially), you'd have to write a script to loop through the user avatars directory and cache it that way.

You also need to remove the avatar from user meta if the user has deleted it.

#4 @boonebgorges
12 years ago

  • Keywords 2nd-opinion added; reporter-feedback removed
  • Milestone changed from Awaiting Review to Future Release

In the short term, r-a-y is right that some sort of intelligent caching in your app is probably the best solution. In fact, good client-side caching is going to go a lot further in terms of speeding up your app than single enhancement that BP could handle server-side.

However, there are a couple of reasons, aside from modemlooper's immediate concern (which is totally valid btw), for rethinking our current avatar scheme:

  • On the default setup, it requires a zillion requests to Gravatar on every page load. This causes problems with strict browser settings for cross-domain requests, with strict SSL enforcement, with latency, with specifying a reliable fallback for users who have not uploaded local avatars, etc. In recent versions of BP it's possible to disable Gravatar at a global level, but most admins will not do so.
  • The current setup is designed to perform, but it involves crawling the avatar directory structure many times during each page load. I haven't done benchmarking, but I'd be willing to bet that it's not as superior to a (properly cacheable) db-based method as it may seem at first blush.
  • Not storing avatar data in the db means that it's impossible to handle avatar data programatically in a variety of interesting ways. For instance, you can't tell with a single query what percentage of your users have local vs Gravatar avatars. I'm sure there's lots of interesting metadata about avatars that could be used to interesting effect by devs if it were only available.

I propose that, in the medium term, we move toward storing avatar information in usermeta. In the past, we have avoided this, because of the problems of joining against huge, unindexed tables. But the refactor discussed in #4060 will make it much more feasible. In particular, converting member queries to use WP_User_Query will mean that we can leverage usermeta-slurping and caching that, in theory, will add no overhead at all.

There will be a lot of work involved in building avatar logic that does the following:
a) determines the proper order of precedence when searching for avatars (local > gravatar > local default)
b) decides when to store/refresh avatar metadata (when a new avatar is uploaded, when an avatar is deleted, when an avatar has been detected at Gravatar)
c) handles group avatars in a similarly performant manner

But I think that most of this work can and should wait until #4060 is fixed (fwiw, it's my first priority in the 1.7 cycle). In the meantime, thoughts welcome.

#5 @modemlooper
12 years ago

I guess I'll intercept the avatar uploads and save meta for now, thanks ray, good suggestion. I'll write a script to add all avatar urls to db to plugin. Boone, I'm glad this is on your brain. The over use of gravatar http request is a total data waste on mobile, luckily we can kill that request.

#6 @DJPaul
6 years ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#7 @DJPaul
6 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.