Make WordPress Core

Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#27304 closed defect (bug) (fixed)

Improve user searching

Reported by: johnbillion's profile johnbillion Owned by: johnbillion's profile johnbillion
Milestone: 4.3 Priority: normal
Severity: normal Version:
Component: Users Keywords: needs-testing has-patch dev-feedback
Focuses: administration Cc:


Performing a search on the Users admin screen is terrible and infuriating. Only the user_login (username) and user_nicename (sanitised username) fields are searched.

None of these fields are ever searched:

  • First name
  • Last name
  • Nickname
  • Display name

Email addresses are only searched if your search query contains an @ symbol.

On the Users screen in Network Admin, it gets worse. The user needs to be aware of the need to use a * wildcard character at the beginning and/or end of the search term, otherwise the search requires an exact match.

We should default to searching everything, all the time, with filters in place to revert the behaviour for large networks which need to control performance.

Attachments (4)

27304.patch (543 bytes) - added by mordauk 10 years ago.
27304.2.patch (555 bytes) - added by mordauk 9 years ago.
27304-tests.patch (1013 bytes) - added by mordauk 9 years ago.
27304.diff (3.0 KB) - added by wonderboymusic 9 years ago.

Download all attachments as: .zip

Change History (25)

#1 @SergeyBiryukov
10 years ago

Related: #22309, #26839.

Last edited 10 years ago by SergeyBiryukov (previous) (diff)

#2 @mordauk
10 years ago

Oh yes please. I've built searches a couple of times for sites that have front-end user directories and have always had to rely on custom queries.

10 years ago

#3 @mordauk
10 years ago

27304.patch sets the fields to be 'user_login', 'user_url', 'user_email', 'user_nicename', 'display_name', instead of just 'user_login', 'user_nicename'.

#4 @johnbillion
10 years ago

#26839 was marked as a duplicate.

#5 @knutsp
10 years ago

Please get this in soon.

#6 @AskKim
10 years ago

Following here since you closed my original ticket. Glad to see you've got a patch for this headache.

#7 @johnbillion
10 years ago

#18183 was marked as a duplicate.

#8 @MathSmath
10 years ago

From a usability perspective, I think it's more complicated than just adding nicename and display name to the search. I think we also need first and last name from the usermeta.

On the user management screen, "Name" is one of the primary fields used to identify users. So you'd (reasonably) think it would be a key consideration in search. But the "name" that's listed is a combination of the first_name and last_name usermeta fields (not your display name or nicename).

If I, as a user, see someone listed named "Matt Smith", and I search for "Matt Smith" and get no results, I (understandably) think that search is broken.

I've also run into something that might be an edge case, but is worth mentioning: you're totally allowed to use the @ symbol in your username (or other user fields). So in assuming that anything with an "@" in it should only search the email field is wonky, IMO. But that's how it's currently implemented.

Aside: am I the only person who thinks there are too many "name" concepts in core? Login, nicename and display name in the users table, PLUS first name, last name and nickname stored in usermeta. Are any of these on the road to deprecation?

#9 @Lohoris
10 years ago

You're not alone @MathSmath, they are definitely too many, when a single field would be enough, besides the username which should be used only to login anyway.

9 years ago

9 years ago

#10 @mordauk
9 years ago

  • Keywords needs-testing added

27304.2.patch is a refreshed patch for the src/ version of trunk.

27304-tests.patch adds some unit tests for searching.

#11 @johnbillion
9 years ago

  • Keywords 4.3-early has-patch added; needs-patch removed
  • Milestone changed from Awaiting Review to Future Release

#12 @obenland
9 years ago

  • Owner set to johnbillion
  • Status changed from new to assigned

#13 @obenland
9 years ago

  • Keywords 4.3-early removed
  • Milestone changed from Future Release to 4.3

9 years ago

#14 @wonderboymusic
9 years ago

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

In 32980:

When searching for users using the search arg in get_users()/WP_User_Query, also search the user's email, url, and display name.

Adds unit tests.

Props mordauk, wonderboymusic.
Fixes #27304.

#15 @ocean90
9 years ago

  • Keywords dev-feedback added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Isn't this a duplicate of #16366? What about the concerns in ticket:16366:4?

Looks like the docs for user_search_columns needs to be updated if this stays.

#16 @wonderboymusic
9 years ago

Because meta query role lookups exist, I am less inclined to worry about the performance hit here. When you hit something like 1,000,000 users or so in the database, NONE of the user queries scale. That is a problem, yes, but for 99% of installs, the user tables are small (when I say "small", I mean less than 1000 users).

Does anyone else want to weigh in here?

#17 @mordauk
9 years ago

I help maintain a site that has over 250,000 users in the database and being able to find a user is far more important than the speed of the query.

For me, and for that site, the performance around searching isn't nearly as important as being able to search.

#18 @rachelbaker
9 years ago

I agree with @mordauk, being able to find users is much more important than the speed of the query. Paging through the User List Table to locate a user is maddening.

Searching for a user by a display name or email (not sure about url) is something I imagine shocks most site owners/admins when they first see the No Results Found response.

I have already used this feature several times since it was added to trunk, so please don't take it away :)

#20 @wonderboymusic
9 years ago

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

In 33116:

After [32980], update the docs to reflect that display_name is now included when searching for users in some scenarios.

Fixes #27304.

#21 @tellyworth
9 years ago

This causes problems on network installs with very large wp_users tables, because only user_login and user_nicename are indexed, so it does a full table scan.

It can be avoided by filtering user_search_columns in a plugin, but it'd be preferable to not be broken out of the box for big installs. One possibility would be to only use indexed columns on multisite. There are probably better options, since obviously multisite is not synonymous with large.

Note: See TracTickets for help on using tickets.