get_pages and get_posts do not work well with private posts

[Otto42]

The get_pages function has no way to retrieve private pages.
The get_posts function uses a post_status parameter, meaning that it can retrieve (and potentially display) private posts regardless of the user.

While get_pages() simply lacks a feature, I would argue that get_posts() is defective in that it can display things that it should not be able to display.

Both of these functions need to be updated to use the get_private_posts_cap_sql() function for building the correct post_status query segment.

[Otto42]

Suggested patch

[ryan]

get_posts and get_pages should be able to directly retrieve any post status, regardless of the current user. Plugins and the admin need to be able to get at anything. Maybe we need some more args. post_statusin => array('publish', 'private'), check_user_caps => true. Something like that.

[westi]

marking as an enhancement

moving to 2.6 for resolving.

[chrislear]

A smaller diff

[chrislear]

I've attached a much smaller diff that works OK for me. I ran it against a fresh Wordpress 2.5.
All it does is include private pages if it's valid to do so in get_pages.
I didn't need the extra post_status argument (or the whitespace changes) from the other diff.

[chrislear]

I should have said that I wanted this because I'm using wp_list_pages in my template header, and I want to show private pages when the user is logged on. Here's the code:

if (is_user_logged_in()) {

$exclude="&exclude=5,7"; But should include private pages

} else {

$exclude="&exclude=7";

}
wp_list_pages("title_li=&sort_column=menu_order&depth=1$exclude" );

[Denis-de-Bernardy]

see also: #4531

[Denis-de-Bernardy]

patch isn't good, see Ryan's comment:

​http://core.trac.wordpress.org/ticket/4711#comment:2

[sillybean]

This issue is causing a number of ripple effects. See #8592 and #6939 for starters. All the attempts to patch those problems have apparently incurred some serious performance issues (see Denis's comments on #8592 and #11697).

Would it make sense to pass these functions an extra argument telling them whether or not to include private posts/pages? If the default is to ignore them, everything would work exactly as it does now, but those of us who do need the private pages would have a way to get them (and we'd have to accept the performance hit).

Another way of looking at it: get_pages serves both template (wp_list_pages) and edit screen (wp_dropdown_pages) functions, and it doesn't know which one will use its output. We could pass an argument based on what the user is trying to do. For example, if $user_is = reading (i.e. it's wp_list_pages calling get_pages), we could check to see whether they can see private content and include things accordingly. If they're writing, we could check to see whether they're allowed to edit private pages, and if so, include those pages in the parent dropdown.

[Otto42]

Replying to ryan:

get_posts and get_pages should be able to directly retrieve any post status, regardless of the current user. Plugins and the admin need to be able to get at anything. Maybe we need some more args. post_statusin => array('publish', 'private'), check_user_caps => true. Something like that.

Okay, given that, there's still a bug. get_pages cannot retrieve private pages, as it has "post_status = 'publish'" hardcoded in its query.

Seems to me that get_pages is redundant anyway, now. One can simply use get_posts with a argument of 'post_type' => 'page' to get pages. The get_pages function should probably be reworked to just point to get_posts.

[markjaquith]

In the dev chat today, people seemed to support Ryan's suggestion of post_status_in and check_user_caps

[ryan]

WP_Query::get_posts() already supports most of this. get_pages() should call get_posts() and the hierarchical post type bits should go in get_posts() or WP_Query::get_posts().

[nacin]

Depending on #12821 I guess.

[sillybean]

The patches on #8592 should resolve this problem and #6939.

[nacin]

Duplicate of #8592.