Site search in "Network Admin" returns less results than expected; frequently none

[tthorp]

In a multi-site Network, a search of "users" or "sites" requires a perfect match of certain fields in order to return result. Typically, for the way I am using it, the result is "No users found."

It seems that the search works fine if the search string is equal to a field value such as "username" or "path", but it does not search last name for matches. Additionally, it would be preferable to users like me if the search string was loosely matched or surrounded with wildcards.

I run a university blog service and we have hundreds of sites and thousands of users, so my use cases that are failing to work are as follows.

1) "FIND USERS BY LAST NAME": navigate to Network Admin > Users and search for a user by typing their last name in the search field in the upper right and pressing search. Currently this search will only find complete and exact matches of usernames. To use an example, Josiah Carberry's username is jcarberr9. I can find him if I search jcarberr9, but not if I search for carberry or Carberry.
2) "FIND SITES BY PORTION OF PATH": navigate to Network Admin > Sites and search for a site by typing a portion of the sitename in the search field in the upper right and pressing search. In my case, it would be useful use a portion of a course code in the search, so if I wanted to see all blogs for the Psychology department, I could just search for PSY.

[johnbillion]

Thanks for the report, tthorp.

Searching users in the network admin was fixed in #32913, which will ship with WordPress 4.4. I'm going to look at improving the results when searching sites too.

[johnbillion]

Actually, #32913 and #27304 didn't address searching the first and last name fields. I'll continue working on this in 4.4.

[tthorp]

Thanks John. We really appreciate your work on this!

I may have adequately described this in the original ticket but in case it helps to clarify, the issue also has to do with network admin site search regarding portions of the url or path.

If a site's url is, say ​http://toppings.pizza.net/pepperoni/ it would be useful (to me) to be able to search "pepper" and have the site returned.

[Fab1en]

Use wildcard by default in site search

[Fab1en]

Here is a first pass : 33185.patch​ make use of wildcards by default when looking at a site path. The behavior for the site's url ​http://toppings.pizza.net/pepperoni/ is the following :

1. before the patch :
   • pepper does not match
   • pepper* matches
   • *peroni does not match
   • pepp*ni does not match
2. after the patch :
   • pepper matches
   • peroni matches
   • adding * anywhere in the search term has no effect : it still matches

Is it acceptable ?

[Fab1en]

Replying to tthorp:

1) "FIND USERS BY LAST NAME": navigate to Network Admin > Users and search for a user by typing their last name in the search field in the upper right and pressing search.

I think this have performance concerns and should be discussed in #27304.

2) "FIND SITES BY PORTION OF PATH": navigate to Network Admin > Sites and search for a site by typing a portion of the sitename in the search field in the upper right and pressing search.

This one is addressed by 33185.patch​.

[tthorp]

Is this patch (33185) in 4.4 v2? I have installed the Beta 4.4 v2 in our QA environment.

The network user search is perfect. Great results there.

Network site search is still returning less results than expected. Your description of the patch sounds great.

Many thanks,

Tim

[Fab1en]

Thanks for your feedback. This patch is not in 4.4 beta2, but you can test it to see if it really solves the issue you reported. You can do this by following the method explained in the handbook (using ​grunt,​Tortoise SVN or ​the command line).

For the command-line, the commands are :

$>wget https://core.trac.wordpress.org/raw-attachment/ticket/33185/33185.patch
...
$>patch -p2 < 33185.patch
patching file wp-admin/includes/class-wp-ms-sites-list-table.php

[tthorp]

Thank you Fab1en. I have tested this patch and it is very effective! Many thanks. -Tim

[johnbillion]

Turns out this is a little more complicated than it looks due to the ability to search by site ID, etc. I've started on some unit tests but they need more work.

[tthorp]

I truly appreciate the work that has been done on this issue since reported. The fact that is could not be incorporated in the 4.4 release is completely understandable but the patches produced to date worked in my testing so I am hoping that the remaining work involved is not of a large magnitude.

In large network administration, the search issue is paramount.

I want to mention that I don't really understand the process here but am asking if we could tag this as a milestone for a specific future release; either 4.5 or 4.6.

Thank you,

Tim

[Fab1en]

I think it's up to the release lead to decide if this should go into the next version or not. For 4.5, Mike Schroder (@mikeschroder) has this role (info is on ​Make Core blog). Mike, could you give us your opinion about this patch please ?

@tthorp : if you want to push for a particular ticket to be included on the next release, you can attend a "bug scrub" meeting that is held each friday on slack (see for example ​this post that list the tickets covered during the 2/5/2016 bug scrub). You can also follow the make/core blog and add a comment to the "call for tickets" post (when there is one) with the ID of the ticket you want to enlight.

For info, the patch 33185.patch​ still applies on the latest trunk.

[kirasong]

Hey there! The suggestion to bring it up in a bug scrub is a good one. We're still in beta and haven't reached RC, so from my perspective, patches from bugs can still land.

Usually the call as to whether a particular patch is suitable for core lands on the ​Component Maintainer(s) and Committers that review it.

In this case, it looks like @johnbillion noted that more tests are needed before it can land in core.

@johnbillion @jeremyfelt @DrewAPicture, have any insight as to what's left here?

[ocean90]

Related: #24833, #21837

[jeremyfelt]

I have a feeling #35791 will help solve a few tickets like this, so I'm leaving a note for later.

[jeremyfelt]

The latest patch on #36675, which implements WP_Site_Query (see #35791) resolves this ticket in the process.

[jeremyfelt]

In 37736:

Multisite: Use WP_Site_Query to power WP_MS_Sites_List_Table.

WP_Site_Query provides for a cleaner prepare_items() method. It significantly improves the search experience in the sites list table:

• In a subdomain configuration, domain and path are searched for a provided terms.
• In a subdirectory configuration, path is searched for a provided term.
• The full domain is searched in a subdomain configuration rather than the portion not matching the network's domain.
• Terms are searched as %term% by default. Adding * in the middle of a term will search %te%rm%.

Props flixos90, Fab1en.
Fixes #33185, #24833, #21837, #36675.

[DrewAPicture]

In 37739:

Docs: Add a missing summary and @since version to the DocBlock for WP_MS_Sites_List_Table::prepare_items().

Also adds a changelog entry for 4.6.0 noting the changeover to get_sites().

Fixes #36675. See #21837, #24833 and #33185.