Skip to:

Opened 10 years ago

Closed 10 years ago

#5734 closed enhancement (fixed)

Members loop inside a BP profile only shows friends of the displayed users.

Reported by: commoneasy's profile CommonEasy Owned by: boonebgorges's profile boonebgorges
Milestone: 2.1 Priority: normal
Severity: normal Version: 1.2.6
Component: Members Keywords: has-patch


I have an extra sub-nav-item right under the friends-nav-item in the buddypress profiles which is supposed to showing friends of friends using bp_has_members( bp_ajax_querystring( 'members' ).'&include=1,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58' ).

I played around with different strings of user ids and I found that users who are not connected to /have a friendship with the displayed users are ignored by the loop. So it is only showing my friends and not all the other user ids parsed with the include statement. So when i pass an string of user ids who are friend of friends it says there are no users found...One way to workaround this problem is to create a whole new nav-item, and put the friends and FOF loop there under sub-nav items. however functions like sort and add friend buttons arent available there. So that actually avoids the problem rather than solving it. However the pastebin of the partial bp-custom is here:

This problem is also reported by me in the support forums and here

and i guess here

I use wordpress 3.9.1 and BP 2.0.1,



Attachments (1)

5734.friend_button.patch (2.8 KB) - added by r-a-y 10 years ago.

Download all attachments as: .zip

Change History (9)

#1 @boonebgorges
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

This behavior is by design. See

You can override it in your own template by adding 'user_id=0' to the params passed to bp_has_members():

if ( bp_has_members( bp_ajax_querystring( 'members' ) . '&include=1,40&user_id=0' ) ) { //...

Please let me know if this doesn't work for you. And if you see fit, please feel free to add a note to that explains the issue (probably under the user_id section)

#2 @CommonEasy
10 years ago

Thanks boonebgorges! I tried user_id=false before, but this actually does work! I will add the comment at the user_id section. Only problems remaining is that the the sort buttons don't work and only the end-friendship buttons are showing and not the add-friendship buttons...any tips?

#3 @boonebgorges
10 years ago

Cool, glad the filtering works!

As for your other questions - I imagine that something is going funky with your use of BP's core templates/AJAX for displaying your content. Sorting depends heavily on the current page, and since your page is custom, it's probably not working. The friendship buttons are probably being rendered incorrectly as well because you're on a friends page, so you'll have to override some defaults. In either case, it's a bit out of BP core's jurisdiction to make these templates portable in the way that you need them to be. What you'll need to do is copy the templates to your own theme/plugin and modify them as necessary to make your customizations work within the context of the friends component. If you need more help with that, the best place to go is the support forums, not Trac. Thanks!

#4 @r-a-y
10 years ago

  • Keywords has-patch added; needs-codex needs-docs removed
  • Milestone set to 2.1
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 2.0 to 1.2.6

About the friendship button not displaying in a member loop on a user's profile page, the issue appears to be because of the block_self parameter in the BP_Button class.

Try out friend_button.patch and see if that works for you, CommonEasy. It might make sense to add these fixes in the BP_Button class instead.

#5 @CommonEasy
10 years ago

  • Milestone 2.1 deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

Hi r-a-y, the patch works! thank you very much! @boonebgorges I updated at the user_id section. Thanks for the help!

#6 @DJPaul
10 years ago

  • Milestone set to 2.1
  • Resolution worksforme deleted
  • Status changed from closed to reopened

Please don't close the ticket. We need to fix the bug for everyone else, too :)

#7 @boonebgorges
10 years ago

It might make sense to add these fixes in the BP_Button class instead.

I think this is right. The definition of "self" is different in the context of a members loop, no matter what the button type. So I think the logic is:

global $members_template;

if ( true === $this->block_self ) {
    if ( $members_template->in_the_loop && bp_get_member_user_id() === bp_loggedin_user_id() ) {
        return false;
    } else if ( bp_is_my_profile() ) {
        return false;

Syntax could obviously be simplified :)

#8 @boonebgorges
10 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from reopened to closed

In 8607:

block_self should not block all buttons when inside a members loop on one's own profile

This changeset reconfigures the block_self logic in BP_Button so that the
bp_is_my_profile() check is skipped when inside of a members loop. This allows
block_self logic to operate properly when inside of a members loop that happens
to appear on the logged-in user's profile page.

Also adds unit tests for the block_self param.

Fixes #5734

Props r-a-y for the initial patch.

Note: See TracTickets for help on using tickets.