[wp-trac] [WordPress Trac] #36508: Call cache_users() when 'fields'=>'all' in WP_User_Query

[WordPress Trac]

#36508: Call cache_users() when 'fields'=>'all' in WP_User_Query
-----------------------------+-----------------------------
 Reporter:  danielbachhuber  |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  Users            |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:  performance
-----------------------------+-----------------------------

Comment (by boonebgorges):

 Yeah, we should do something here. Not totally sure what. A couple
 thoughts:

 - This is not a new issue. [32001] pointed the role query at the correct
 blog, but the query has always taken place.
 - `fields=all` doesn't interact with any cache - either for usermeta or
 for user objects themselves

 If we call all of `cache_users()`, we have essentially eliminated the
 distinction between `fields=all` and `fields=all_with_meta`. See
 [attachment:36508.diff]. On many sites this would be an improvement. But
 usermeta also tends to be abused, so that fetching usermeta for all users
 in a query can significantly affect memory footprint. This is especially
 worrisome given that `all` is the default value of `fields`.

 A couple of other possibilities:
 1. We introduce a standalone function for priming the `wp_x_capabilities`
 cache, and call that  - either instead of `cache_users()` or as an option
 within `cache_users()` - when `fields=all`.
 2. We lazyload usermeta in `WP_User_Query` loops. Usermeta, including
 capabilities, wouldn't be loaded until it's requested. This would mean
 some refactoring of `WP_User`, so that capabilities aren't loaded into
 user objects until they're requested (so `WP_User::allcaps` etc would be
 handled via magic method or something like that). This is obviously much
 more extensive, but has the potential to improve performance across the
 board when using either `WP_User_Query` or `WP_User`.

 @danielbachhuber Do you have thoughts about the best strategy?

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