no way to retrieve group avatar from ID

[mikepratt]

bp_group_avatar does not return the group avatar when fed a group ID.

If it was not meant to, then there is no way to return a group avatar via a group ID.

The following works, to some degree, as a workaround:

$bp->groups->current_group = new BP_Groups_Group( $group_id );
bp_group_avatar()

bp_group_avatar() returns the group thumb even if 'type' is set to 'full'

This is basically a request for the exposing of all group related fields (name, desc, avatar, etc) for a given ID.

Otherwise it forces the use of a loop or object instantiation just to return some data

[mikepratt]

bp_core_fetch_avatar('object=group&item_id=GROUP_ID') does the trick.

[calvin_42]

bp_get_group_avatar() should accept a group_id via item_id like the others templatetags.

I have enclosed a patch.

[calvin_42]

Patch

[cnorris23]

The other component avatar functions don't accept ids as parameters. The reason for this is because they are being used within their respective loops, which is why it wasn't done like this in the first place. As mikepratt stated earlier bp_core_fetch_avatar works just fine for this. The bp_get_*_avatar() functions are just a wrapper for bp_core_fetch_avatar() to be used inside the component's loop. That being said, if it were to be done, you'd need to update the other functions like bp_get_member_avatar(), bp_displayed_user_avatar(), bp_loggedin_user_avatar(), and bp_get_blog_avatar(). The patch should also be created against trunk rather than the 1.2 branch.

[DJPaul]

I don't see why bp_displayed_user_avatar() or bp_loggedin_user_avatar() would need an $id parameter. Those functions have very specific purposes. I'm interested in hearing what others think about modifying the object loop avatar functions to take an ID. I can sort of see the utility in that, but I wonder if better documentation that says "you can/cannot use this outside its loop" is all that's required.

[boonebgorges]

I don't see why bp_displayed_user_avatar() or bp_loggedin_user_avatar() would need an $id parameter.

Agreed - was anyone suggesting that?

There's a sense in which it would be quite nice for all template tags to have this feature, and technically there's no reason why it couldn't be done. I should note that WP itself is a mixed bag here; get_the_title() takes an optional $id, while get_the_content() does not.

We should be consistent, though. So that means we need a good reason for deciding one way or the other. One argument for rejecting the proposal (to make template tags usable outside the loop) is that such a change might encourage inefficiency. The loops are (supposed to be) optimized, minimizing the number of DB calls. If every template tag allows you to make independent queries, you could get unconscientious developers building slow sites and then blaming it on BP.

[cnorris23]

@DJPaul, I'm with you. I can kind of see how it would be useful, but I think it would the better option would be to get things documented and add in the disclaimer that they're only to be used in within their respective loops.

@boonegorges I kind of suggested it. I should have left bp_displayed_user_avatar() or bp_loggedin_user_avatar() out, because, as DJPaul said, they have very specific purposes and I knew that.

[DJPaul]

My view is template functions shouldn't take a user ID to fetch something outside of the current loop object. Close?

[boonebgorges]

Close. If someone wants to write a patch with wrapper functions for group and user avatars, that would probably be fine. But they should not go in the template tags.

[johnjamesjacoby]

Moving closed ticket out of Awaiting Review.

[johnjamesjacoby]

Back from the dead, I'd like to propose we enhance bp_get_group_avatar() in a few different ways:

• Allow it to work on the Group Creation screen.
• Provide sane defaults in the event it's called outside a group loop.

These two small tweaks eliminate the need to guess at whether to use bp_core_fetch_avatar() or bp_get_group_avatar() for the group creation screen, and allow bp_get_group_avatar() to always put out some image, rather than create PHP notices or exit early.

Patch imminent.

[DJPaul]

Patch looks mostly okay, allowing for @johnjamesjacoby's unorthodox preference for splitting short ternaries across multiple lines. :) I think we also need to:

• The new Unknown Group string needs the context parameters added, I can see the string as-is causing confusion for translations.
• Someone needs to test this on current trunk and confirm it works as intended.

[DJPaul]

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/