[wp-trac] [WordPress Trac] #37499: Multi-site: WP_User_Query:prepare_query() bug leads to user meta query with blog_id 0

WordPress Trac noreply at wordpress.org
Thu Jul 28 15:05:34 UTC 2016


#37499: Multi-site: WP_User_Query:prepare_query() bug leads to user meta query with
blog_id 0
--------------------------+--------------------
 Reporter:  stephdau      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.6
Component:  Users         |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+--------------------
Description changed by stephdau:

Old description:

> In `WP_User_Query:prepare_query()`, one can find the following line, to
> "Prevent extra meta query" (SIC):
> {{{
> $qv['blog_id'] = $blog_id = 0;
> }}}
>
> Setting the `blog_id` to `0` was, in previous versions of that code (from
> r32207), to make the code not proceed with further test cases afterward,
> as one can find `if ( $blog_id &&` peppered throughout this method.
>
> In 4.6, this method has changed (r37360) to have more processing after
> this `blog_id` reset happens, leading to a query being place with `AND
> blog_id = 0` instead of the intended proper `blog_id` that exists before
> that reset. Said query therefore becomes "invalid", since it will not
> return the expected blog users.
>
> In my experience, this happens at least when `wp_dropdown_users()` tries
> to get a list of the blog's users in the post/page edit screen.
>
> Both r32207 and r37360 by @ boonebgorges :)
>
> Sample data lifespan (note how `blog_id` becomes `0`):
> {{{
> get_users(): array (
>   'blog_id' => '114310708',
>   'include' => '',
>   'exclude' => '',
>   'orderby' => 'display_name',
>   'order' => 'ASC',
>   'who' => 'authors',
>   'fields' =>
>   array (
>     0 => 'ID',
>     1 => 'user_login',
>     2 => 'display_name',
>   ),
>   'count_total' => false,
> )
>

> User query construct: array (
>   'blog_id' => '114310708',
>   'include' => '',
>   'exclude' => '',
>   'orderby' => 'display_name',
>   'order' => 'ASC',
>   'who' => 'authors',
>   'fields' =>
>   array (
>     0 => 'ID',
>     1 => 'user_login',
>     2 => 'display_name',
>   ),
>   'count_total' => false,
> )
>

> [28-Jul-2016 14:51:30 UTC] Bad WP_User_Query attempt. Args:
> Array
> (
>     [blog_id] => 0
>     [role] =>
>     [role__in] => Array
>         (
>         )
>
>     [role__not_in] => Array
>         (
>         )
>
>     [meta_key] =>
>     [meta_value] =>
>     [meta_compare] =>
>     [include] =>
>     [exclude] =>
>     [search] =>
>     [search_columns] => Array
>         (
>         )
>
>     [orderby] => display_name
>     [order] => ASC
>     [offset] =>
>     [number] =>
>     [paged] => 1
>     [count_total] =>
>     [fields] => Array
>         (
>             [0] => ID
>             [1] => user_login
>             [2] => display_name
>         )
>
>     [who] => authors
>     [has_published_posts] =>
> )
> }}}

New description:

 In `WP_User_Query:prepare_query()`, one can find the following line, to
 "Prevent extra meta query" (SIC):
 {{{
 $qv['blog_id'] = $blog_id = 0;
 }}}

 Setting the `blog_id` to `0` was, in previous versions of that code (from
 r32207), to make the code not proceed with further test cases afterward,
 as one can find `if ( $blog_id &&` peppered throughout this method.

 In 4.6, this method has changed (r37360) to have more processing after
 this `blog_id` reset happens, leading to a query being place with `AND
 blog_id = 0` instead of the intended proper `blog_id` that exists before
 that reset. Said query therefore becomes "invalid", since it will not
 return the expected blog users.

 In my experience, this happens at least when `wp_dropdown_users()` tries
 to get a list of the blog's users in the post/page edit screen.

 Both r32207 and r37360 by @ boonebgorges :)

 Sample data lifespan (note how `blog_id` becomes `0`):
 {{{
 get_users(): array (
   'blog_id' => '114310708',
   'include' => '',
   'exclude' => '',
   'orderby' => 'display_name',
   'order' => 'ASC',
   'who' => 'authors',
   'fields' =>
   array (
     0 => 'ID',
     1 => 'user_login',
     2 => 'display_name',
   ),
   'count_total' => false,
 )


 User query construct: array (
   'blog_id' => '114310708',
   'include' => '',
   'exclude' => '',
   'orderby' => 'display_name',
   'order' => 'ASC',
   'who' => 'authors',
   'fields' =>
   array (
     0 => 'ID',
     1 => 'user_login',
     2 => 'display_name',
   ),
   'count_total' => false,
 )


 Bad WP_User_Query attempt. Args:
 Array
 (
     [blog_id] => 0
     [role] =>
     [role__in] => Array
         (
         )

     [role__not_in] => Array
         (
         )

     [meta_key] =>
     [meta_value] =>
     [meta_compare] =>
     [include] =>
     [exclude] =>
     [search] =>
     [search_columns] => Array
         (
         )

     [orderby] => display_name
     [order] => ASC
     [offset] =>
     [number] =>
     [paged] => 1
     [count_total] =>
     [fields] => Array
         (
             [0] => ID
             [1] => user_login
             [2] => display_name
         )

     [who] => authors
     [has_published_posts] =>
 )
 }}}

--

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


More information about the wp-trac mailing list