[wp-trac] [WordPress Trac] #15786: Many Users Causes Export Page to Fail

[WordPress Trac]

#15786: Many Users Causes Export Page to Fail
-----------------------------+-----------------------
 Reporter:  filosofo         |       Owner:  duck_
     Type:  defect (bug)     |      Status:  assigned
 Priority:  highest omg bbq  |   Milestone:  3.1
Component:  Export           |     Version:  3.1
 Severity:  blocker          |  Resolution:
 Keywords:  needs-patch      |
-----------------------------+-----------------------

Comment (by duck_):

 Also crashing on the posts list (edit.php), because of author dropdown in
 quick edit, and on single post edit page (post.php), because of the
 authors meta box.

 Example fatal error:

 {{{
 Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
 allocate 32 bytes) in /home/sites/trunk/wp-includes/wp-db.php on line 1399

 Call Stack:
     0.0008     833296   1. {main}() /home/sites/trunk/wp-admin/edit.php:0
     0.2207   33044032   2. WP_Posts_List_Table->inline_edit()
 /home/sites/trunk/wp-admin/edit.php:250
     0.2218   33055688   3. wp_dropdown_users() /home/sites/trunk/wp-
 admin/includes/class-wp-posts-list-table.php:778
     0.2218   33066776   4. get_users() /home/sites/trunk/wp-
 includes/user.php:970
     0.2218   33069136   5. WP_User_Query->__construct() /home/sites/trunk
 /wp-includes/user.php:598
     0.2219   33073800   6. WP_User_Query->query() /home/sites/trunk/wp-
 includes/user.php:394
     0.3063   40401976   7. cache_users() /home/sites/trunk/wp-
 includes/user.php:522
     0.4526   62365728   8. _fill_many_users() /home/sites/trunk/wp-
 includes/pluggable.php:155
     0.4587   63220632   9. get_user_metavalues() /home/sites/trunk/wp-
 includes/user.php:1098
     0.4686   67508744  10. update_meta_cache() /home/sites/trunk/wp-
 includes/user.php:1041
     0.5072   71219944  11. wpdb->get_results() /home/sites/trunk/wp-
 includes/meta.php:327
 }}}

 As you can see this is being caused by trying to cache every single user
 matched by the query (approximately 6,500 of them). I tried just removing
 the call to cache_users in WP_User_Query->query() as an experiment, and
 although there was no longer a fatal error it was still crippled by the
 6,500 database queries to build each user object and still used ~226MB
 memory (not looked into where).

 For comparison 3.0.3 performs two queries, one to get the relevant user
 IDs (see `get_editable_user_ids`, now deprecated) and then another to get
 whole user row for each ID (`wp_dropdown_users` using the include
 parameter). So the second query has a huge IN condition as part of the
 WHERE clause and the browser struggles to render such a massive select
 dropdown (good reason for autosuggest I guess), but no fatal error
 (~65.114MB memory usage in testing with 8,500+ users).

 ''Example patch'' 15786.export.diff to only include users with posts in
 the export dropdowns, but I don't think it will scale for a large number
 of different post authors with the current state of wp_dropdown_users and
 get_users/WP_User_Query. Should wp_dropdown_users just not even use
 get_users/WP_User_Query?

 I also noticed that the user dropdowns when editing a post now show all
 users, not just those who have a user_level != 0 (that's 3.0.3 behaviour,
 again see `get_editable_user_ids`).

 Couple of related changesets: [15539], [15542]

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15786#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software