Skip to:

Opened 10 years ago

Closed 10 years ago

#5659 closed defect (bug)

When querying users with usermeta, if none are found, `bp_core_get_users` returns all users

Reported by: needle's profile needle Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Members Keywords: good-first-bug close


If I perform a query for users with a particular meta_key/meta_value combination via bp_core_get_users(), BP_User_Query->prepare_user_ids_query() constructs a query which returns all users. This does not seem to me to be expected behaviour - I would expect no users to be returned.

The source of the issue begins at line 380 of bp-core-classes.php:

$found_user_ids = $wpdb->get_col( $meta_sql );

if ( ! empty( $found_user_ids ) ) {
	$sql['where'][] = "u.{$this->uid_name} IN (" . implode( ',', wp_parse_id_list( $found_user_ids ) ) . ")";

If no users are found, then the query does not restrict by user_id at all. Surely there needs to be an amendment to the query if $found_user_ids is empty. Something simple like this might suffice:

$found_user_ids = $wpdb->get_col( $meta_sql );

if ( ! empty( $found_user_ids ) ) {
	$sql['where'][] = "u.{$this->uid_name} IN (" . implode( ',', wp_parse_id_list( $found_user_ids ) ) . ")";
} else {
	$sql['where'][] = "u.{$this->uid_name} = '0'";

This has the desired effect, but is probably inefficient. I defer to the SQL experts here to write something more elegant.

Change History (7)

#1 @boonebgorges
10 years ago

  • Keywords needs-refresh needs-unit-tests added
  • Milestone changed from Awaiting Review to 2.1

Thanks for the report. Your solution is pretty close to what is needed (we generally use the $no_results['where'] clause instead, which speeds up the query; see eg the way 'user_id' is parsed in BP_User_Query). If you'd like to write a BP patch using this technique, please do.

Unit tests are also needed to demonstrate this behavior.

#2 @DJPaul
10 years ago

  • Keywords needs-patch good-first-bug added; needs-refresh removed

This would be pretty nice to fix for 2.1 as it seems an egregious bug. The original reporter and Boone describe the best way to fix this ticket, so the remaining work is to create a patch, and write some unit tests.

This should be a good way into learning how to write BuddyPress unit tests for contributors who have created one or two BuddyPress fixes before.

#3 @DJPaul
10 years ago

  • Keywords early added
  • Milestone changed from 2.1 to 2.2
  • Owner set to DJPaul
  • Status changed from new to assigned

#4 @DJPaul
10 years ago

  • Owner DJPaul deleted

#5 @DJPaul
10 years ago

  • Keywords early removed

#6 @Mamaduka
10 years ago

  • Keywords close added; needs-unit-tests needs-patch removed

This issue was fixed with 9051.

#7 @boonebgorges
10 years ago

  • Milestone 2.2 deleted
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.