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 | 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)
Change History (6)
#3
@
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 :)
What's a good solution to this? Checking (int)$limit instead?