Skip to:
Content

BuddyPress.org

Opened 15 years ago

Closed 14 years ago

#1991 closed defect (bug) (fixed)

bp_has_members - can't set unlimited per_page

Reported by: djpaul's profile DJPaul Owned by:
Milestone: 1.5 Priority: major
Severity: Version:
Component: Core Keywords: has-patch
Cc:

Description

Using bp_has_members(), it is impossible to fetch a list of all of the members (i.e. one page, all users). The problem is that when the per_page value gets to, for example, get_users(), that function's $limit variable is actually a string so it passes as true for this check (on line 179 as per BP 1.2):

{{
if ( $limit && $page )
}}

Attachments (1)

1991.patch (1.6 KB) - added by boonebgorges 14 years ago.

Download all attachments as: .zip

Change History (6)

#1 @boonebgorges
14 years ago

  • Component set to Core

What's a good solution to this? Checking (int)$limit instead?

#2 @djpaul
14 years ago

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

(In [3749]) Allow unlimited per_page setting for members loop. Fixes #1991

#3 @boonebgorges
14 years ago

  • Keywords has-patch added
  • Priority changed from minor to major
  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm reopening this ticket. Paul, your fix meant that the $limit param of BP_Core_User::get_users() was never null. And the default value of $page is set to 1. That means that, in some places where no pagination data at all is passed to bp_has_members(), you end up with $limit = 1 and $page = 1, meaning that a single member is returned. (This happens, for instance, in the friends list that appears on the Send Invites tab of groups.)

I have attached what seems like a safer fix, namely one that casts $limit as an integer, so that the $limit check that you refer to is actually respected when a value of 0 is passed.

I'd like a second opinion about this before committing, because this touches a lot of stuff throughout BP. But I've been staring at it for about an hour and I'm reasonably sure that this is the solution :)

@boonebgorges
14 years ago

#4 @DJPaul
14 years ago

I have not tested this but, on review, I believe your changes to be correct as you describe.

#5 @boonebgorges
14 years ago

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

(In [4330]) Fixes BP_Core_User::get_users() so that a numeral value default value is passed as the limit param. Fixes #1991

Note: See TracTickets for help on using tickets.