wp_list_pages consume a lot of memory

[horaciod]

When we use wp_list_pages in installatiosn with lots of pages (in my case 106 with a lot of text inside ) this function use get_pages (posts.php) which has a get_results of the posts completes with a "select *" but only id,post_title, post_parent is needed.
Maybe you can use a nuew option to wp_list_pages or get_pages with the list of fields to retrieve.
I´m making a patch but first i´m studing the code rules of wordpress.
This Affects a wpdtree plugin and other which use get_pages. In my case this select break the connection with mysql in a Shared web server.

[mrmist]

I'm pretty sure that there's already a ticket floating around with a patch for wp_list_pages. Can't find it just now. I agree with the sentiment though.

[horaciod]

Replying to mrmist:

I'm pretty sure that there's already a ticket floating around with a patch for wp_list_pages. Can't find it just now. I agree with the sentiment though.

i've made a search too but nothing found.

[mrmist]

Yep. Must have been another query.

needs a patch so I doubt it will make 2.7.1

[Denis-de-Bernardy]

dup of #8492

[Denis-de-Bernardy]

re-opening as it's actually a different bug. the two are related though.

[hakre]

Just found while taking a look into this ticket. wp_page_menu improvements.

[hakre]

new argument: fields.

[hakre]

patch added, should to the job. set the fields - argument to 'ID, post_title, post_parent'. did work like a charm for me.

cache only works on default '*' set of fields. it can make sense to use the $fields parameters content as part of the cache key and enable caching for certain type of queries as well.

addtionally the docblock has been extended to have a description of all parameters. all but author.

[hakre]

Update patch to have authors describben as well. Link to codex added.

[hakre]

Patch contained errors. Fixed.

[Denis-de-Bernardy]

I *think* that this:

wp_cache_set( 'get_pages', $cache, 'posts' );

... is needed.

what is missing and may not necessarily be needed is:

update_post_cache($pages);

that being said, adding such a call will tremendously speed things up when generating permalinks, since it saves one query per missed cache hit.

maybe there is a need for an extra cache group, for use by permalinks.

[Denis-de-Bernardy]

patch is broken again. dev feedback would be useful, too...

[Denis-de-Bernardy]

moving to future, as there are a couple of related bugs on wp_list_pages being slow.

[wonderboymusic]

for 500 pages with 20 paragraphs of post_content each, it consumes 2MB for * and 300KB for ID, post_title, post_parent

Since get_pages() uses direct SQL, we can accomplish this without #19866. Officially a fan.

[wonderboymusic]

Actually no, scratch that. This would require a bunch of gymnastics to avoid caching the fragmented results. Not a big enough performance gain to warrant it. Would also require passing fields down to other functions like get_page_children(). I can see why no one has refreshed this patch in 5 years.