WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 months ago

#15459 new enhancement

Need Better Page Hierarchy Display Algo

Reported by: truthmedia Owned by:
Priority: normal Milestone: Future Release
Component: Performance Version: 3.0.1
Severity: normal Keywords: needs-patch
Cc: warkior, batmoo@…

Description

WordPress 3.0.1

File: /wp-admin/includes/post.php

Lines: 904-912

Code:

	// Hierarchical types require special args.
	if ( is_post_type_hierarchical( $post_type ) ) {
		$query['orderby'] = 'menu_order title';
		$query['order'] = 'asc';
		$query['posts_per_page'] = -1;
		$query['posts_per_archive_page'] = -1;
	}

	wp( $query );

The code in the area mentioned above causes our site to use over 170mb of memory on each load of the Pages index. This really should be improved to accommodate sites that have large amounts of hierarchical data. Looks to me like it's pulling all the data for all the pages on the site. Perhaps a solution where unnecessary data is not included might be better here (such as content or excerpt).

Attachments (1)

15459.diff (2.7 KB) - added by nacin 14 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 scribu3 years ago

  • Keywords 3.2-early added; memory pages hierarchy removed
  • Milestone changed from Awaiting Review to Future Release
  • Type changed from defect (bug) to enhancement

For taxonomies, we store the tree of IDs and then query based on that. We could do the same for hierarchical post types.

comment:2 scribu2 years ago

  • Keywords 3.2-early removed

This would require quite a bit of refactoring; no patch in sight.

comment:3 SergeyBiryukov2 years ago

  • Keywords needs-patch added

comment:4 duck_19 months ago

Closed #19285 as dupe.

Related change sets [3564], [3727].

comment:6 nacin14 months ago

Here's a quick patch that breaks all over the place but could be a good starting point for someone wishing to solve this.

Essentially, here's what we currently do:

  • Query all posts
  • Group them based on ID and post_parent
  • Begin rendering posts until we've reached the total to display per page

What we should do instead:

  • Query all IDs and post parents
  • Group them
  • Figure out what posts we need to grab to display the right number on a page
  • Use _prime_post_caches() to pull those specific posts into cache
  • Render those posts

Querying all IDs and parents still isn't ideal, but it's a step in the right direction. Without MPTT this is not easy.

nacin14 months ago

comment:7 nacin14 months ago

Here's a quick patch that breaks all over the place but could be a good starting point for someone wishing to solve this.

A note, it's a total duck punch. The idea is a good starting point. The code is not.

comment:8 JustinSainton14 months ago

Certainly quite dated, but I wonder if anything ever happened here or if anything can be salvaged -

http://gsoc2009wp.wordpress.com/tag/mptt/

comment:9 batmoo7 months ago

  • Cc batmoo@… added
Note: See TracTickets for help on using tickets.