[wp-trac] [WordPress Trac] #36675: WP_MS_Sites_List_Table should use WP_Site_Query

[WordPress Trac]

#36675: WP_MS_Sites_List_Table should use WP_Site_Query
--------------------------------+------------------------
 Reporter:  spacedmonkey        |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  4.6
Component:  Networks and Sites  |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  multisite
--------------------------------+------------------------
Changes (by flixos90):

 * keywords:  needs-patch => has-patch


Comment:

 [attachment:36675.diff] makes use of `WP_Site_Query` in
 `WP_MS_Sites_List_Table`. Replacing the SQL with the arguments for the
 site query was pretty straightforward. In the implementation I use
 `WP_Site_Query` directly to be able to access the `$found_sites` property
 as well (and `get_sites()` isn't merged yet anyway). Since the list table
 expects the sites to be arrays, I only query the IDs and run them through
 `get_site( $id, ARRAY_A )` afterwards.

 A small exception was how the search in the list table currently works.
 `WP_Site_Query` didn't natively support the way wildcards are used in the
 search there yet. That's why I also made a minor modification in
 `WP_Site_Query` itself, allowing to pass asterisks into the search string.
 When doing so, these asterisks will be replaced by `%` and not be escaped
 so that they act as wildcards. With that change it is possible to continue
 using the list table search like before.

 Regarding the total count of sites, I set the argument `no_found_rows` to
 false as long as we're not in a "large network" (similar like the count
 wasn't calculated before in that case).

 Another thing we might wanna think about is whether we should move the
 search by IP address bit into `WP_Site_Query` or not. While it would
 enhance the search, I think that's a very rare use-case and it needs to
 make an additional database query (or JOIN), so I personally would leave
 it in the `WP_MS_Sites_List_Table` class - still that's something to
 consider.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36675#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform