members loop query bug with the bp_use_legacy_user_query filter

[DJPaul]

When the bp_use_legacy_user_query filter is used to switch BP to the pre-1.7 member loop query changes, and you pass the type=alphabetical argument to bp_has_members(), a bug introduced in r7700 (probably BP 1.9.1) causes members to appear many times in the members loop.

[DJPaul]

Best way to recreate this is by adding the following to a mu-plugins helper, and then visiting the members directory:

<?php
add_filter( 'bp_use_legacy_user_query', '__return_true' );
add_filter( 'deprecated_function_trigger_error', '__return_false' );

add_filter( 'bp_ajax_querystring', function( $retval ) {
	return 'type=alphabetical';
}, 1000 );

[boonebgorges]

r7700

Son of a gun.

Haven't fully tested yet, but it looks like this is a regression in 2.0.

​https://buddypress.trac.wordpress.org/browser/branches/1.9/bp-core/bp-core-classes.php#L256
​https://buddypress.trac.wordpress.org/browser/branches/2.0/bp-core/bp-core-classes.php#L239

[DJPaul]

Just checked -- r7700 was introduced in trunk for 2.0, not 1.9.1. I misread the commits logs when chasing it down earlier. So it is a regression in 2.0.

[boonebgorges]

In 8289:

Reintroduce DISTINCT keyword to BP_Core_User::get_users()

The lack of DISTINCT was causing duplicate entries when joining against the
xprofile fields for the purposes of alphabetical sorts.

Reverts part of r7700. See #5303

Fixes #5550

[boonebgorges]

In 8290:

Reintroduce DISTINCT keyword to BP_Core_User::get_users()

The lack of DISTINCT was causing duplicate entries when joining against the
xprofile fields for the purposes of alphabetical sorts.

Reverts part of r7700. See #5303

Fixes #5550