Skip to:
Content

BuddyPress.org

Opened 14 years ago

Closed 11 years ago

#3126 closed defect (bug) (no action required)

Sorting users alphabetically produces inconsistent results

Reported by: dimitryz's profile dimitryz Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.2.8
Component: Core Keywords: needs-patch
Cc:

Description

When searching for members in the members/index.php page, a search for the word Montreal returns all members with Montreal in the user data table. This is consistent for every sort order (active, latest registrations) except for the alphabetically sort order: Montreal will only be looked for in the full_name data field.

This is very confusing. The expected result is that any ordering should produce the same results.

I'm attaching a patch that makes all sorting of the members list produce the same results. I would like to see this brought into the core. If this feature was intentional, perhaps there is a more abstract way of searching only for the user-name (e.g. as an extra parameter in the BP_Core_User::get_users)

Attachments (1)

bp-core-classes.patch (1.3 KB) - added by dimitryz 14 years ago.

Download all attachments as: .zip

Change History (9)

#1 @dimitryz
14 years ago

  • Summary changed from Sorting users alphabetically producess inconsistent results to Sorting users alphabetically produces inconsistent results

#2 @cnorris23
14 years ago

  • Keywords needs-patch added; members search alphabetically removed
  • Type changed from task to defect

You can't use "ORDER BY u.display_name ASC" here, because display_name may not be set if "Disable BuddyPress to WordPress profile syncing?" is set to "no." I'm not sure removeing the other "if ( 'alphabetical' == $type )" statements is appropriate either.

#3 @dimitryz
14 years ago

There will have to be a left join in there like:

"LEFT JOIN {$bp->profile->table_name_data} name_field
        ON name_field.field_id = 1
       AND name_field.user_id = u.id"

Then the ordering...

"ORDER BY username"

Finally, the select statement

"name_field.value AS 'username'"

#4 @DJPaul
14 years ago

display_name is a default WordPress user setting, so it would always be set to something. It might just not match the BuddyPress user name (log in name).

#5 @DJPaul
14 years ago

  • Milestone changed from Awaiting Review to 1.3

#6 @sushkov
14 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

#7 @DJPaul
14 years ago

  • Keywords needs-patch added; has-patch needs-testing removed
  • Milestone changed from 1.3 to Future Release

The problem occurs only when searching. The issues concerns when $sqlwhere_searchterms? is set. The display_name solution isn't appropriate because, as cnorris23 said, those fields are not guaranteed to match for a user. The join that dimitryz proposes is what is already implemented.
I have spent a long time looking at fixing this properly and cannot find a way of doing it while the user's name (via BP_XPROFILE_FULLNAME_FIELD_NAME) and the rest of the profile fields are in the same table. It may be possible with a subquery but I am not sure, plus I don't know how slow those things are. Punting the ticket to take another look at in a future 1.3.x release.

#8 @boonebgorges
11 years ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Severity set to normal
  • Status changed from new to closed

I don't think this is an issue anymore. For one thing, BP_Core_User::get_users() has been deprecated in favor of BP_User_Query. Furthermore, BP_User_Query uses a subquery for search term matching, not a join, which should mean that sort order and filtering are totally independent of each other in these sorts of cases.

If I'm wrong about this, please feel free to reopen the ticket with details to reproduce.

Note: See TracTickets for help on using tickets.