id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
9864,Performance issues with large number of pages,pp19dd,,"'''Environment:'''

- Default install, default theme, no plugins, reasonable server configuration (typical execution, memory limits).  In my particular case, that was set to 30 seconds, 384 MB.

'''To reproduce:'''

- Create a large number of pages (5,000+)[[BR]]
- Try to edit a page

'''What happens:'''

- Maximum execution time error

{{{
Fatal error: Maximum execution time of 30 seconds exceeded in \wp-includes\post.php on line 1998
}}}

'''Workaround to prevent error:'''

- set_time_limit to 0 as server admin

'''My diagnosis:'''

Suspect that the immediate problem is that get_pages() inside wp-admin/post.php, line 2173,  performs a query that selects EVERYTHING:

{{{
$query = ""SELECT * FROM $wpdb->posts $join WHERE (post_type = 'page' AND post_status = 'publish') $where "";
}}}

Now, in this case this query (AFAIK) is just supposed to pull up the page list (with IDs, titles and parents).  What it actually does is it pulls up ALL of the post data.  This works fine for low number of pages, but on a larger data set this causes a chokepoint.  After all, the end result is just supposed to be a dropdown with a list of pages.


'''Workaround to improve performance:'''

- comment out line 273 in wp-admin\edit-page-form.php and skip displaying the page parent in the edit screen

'''The bigger picture:'''

Well, the ENTIRE list of pages is queried in this 'edit page' screen (see screenshot # 2 - with a dropdown that contains 5,000+ entries.)  I think this is a design limitation and it looks clumsy once the list gets larger.  Rather than patch the display routines, I think this thing needs to be replaced with something that can search / paginate piecemeal server-side.
",defect (bug),assigned,normal,Future Release,Performance,2.7.1,normal,,,mpretty@… joachim.kudish@… ben@…