Skip to:

Opened 14 years ago

Closed 6 years ago

#2152 closed enhancement (maybelater)

no way to retrieve group avatar from ID

Reported by: mikepratt's profile mikepratt Owned by: calvin_42's profile calvin_42
Milestone: Priority: normal
Severity: normal Version:
Component: Groups Keywords: needs-testing, needs-refresh, trac-tidy-2018


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() 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

Attachments (2)

patch.diff (1.3 KB) - added by calvin_42 13 years ago.
2152.01.patch (1.8 KB) - added by johnjamesjacoby 9 years ago.

Download all attachments as: .zip

Change History (20)

#1 @mikepratt
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#2 @calvin_42
13 years ago

  • Component set to Core
  • Resolution fixed deleted
  • Status changed from closed to reopened

#3 @calvin_42
13 years ago

  • Component changed from Core to Groups
  • Owner set to calvin_42
  • Status changed from reopened to accepted
  • Version set to 1.3

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

I have enclosed a patch.

13 years ago


#4 @cnorris23
13 years ago

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.

#5 @DJPaul
13 years ago

  • Milestone set to Awaiting Review
  • Priority changed from major to normal
  • Version changed from 1.3 to 1.2

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.

#6 @boonebgorges
13 years ago

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.

#7 @cnorris23
13 years ago

@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.

#8 @DJPaul
13 years ago

  • Keywords dev-feedback added

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

#9 @boonebgorges
13 years ago

  • Resolution set to wontfix
  • Status changed from accepted to closed

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.

#10 @johnjamesjacoby
13 years ago

  • Keywords dev-feedback removed
  • Milestone changed from Awaiting Review to 1.5
  • Severity set to normal
  • Version 1.2 deleted

Moving closed ticket out of Awaiting Review.

#11 @johnjamesjacoby
9 years ago

  • Milestone changed from 1.5 to 2.3
  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

#12 @DJPaul
9 years ago

  • Keywords has-patch added
  • Milestone changed from 2.3 to 2.4

#13 @DJPaul
9 years ago

  • Keywords needs-testing good-first-bug added

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.

#14 @DJPaul
9 years ago

  • Milestone changed from 2.4 to 2.5

#15 @DJPaul
8 years ago

  • Keywords needs-refresh added; has-patch removed
  • Milestone changed from 2.5 to Future Release

#16 @DJPaul
8 years ago

  • Keywords good-first-bug removed

#17 @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
or find us on Slack, in the #buddypress channel:

#18 @DJPaul
6 years ago

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