Fix #8592: Include private pages in parent dropdown for users with read_private_posts capability

[Vedanshmini26]

Core Trac: https://core.trac.wordpress.org/ticket/8592

Problem
Private pages do not appear in the Parent dropdown of the Page Attributes metabox when editing a page, nor in the Parent dropdown within the Quick Edit row on the Pages list screen. This makes it impossible to create a hierarchy of private pages through the WordPress admin UI, forcing users to either use plugins or avoid private pages entirely when building hierarchical page structures.

Root Cause
Both the Page Attributes metabox (page_attributes_meta_box() in meta-boxes.php) and the Quick Edit dropdown (class-wp-posts-list-table.php) build their $dropdown_args without a post_status argument. This means they rely on get_pages() which defaults to post_status = 'publish' — private pages are never included.

The filters page_attributes_dropdown_pages_args and quick_edit_dropdown_pages_args were added in 3.3 to allow plugins to work around this, and get_pages() has supported multiple statuses since 3.2. However, core itself never used these capabilities to include private pages based on user permissions — the burden was left entirely on plugins.

Solution
Added a capability check in both locations before the existing filters are applied. When the current user has the read_private_posts capability for the post type (maps to read_private_pages for the built-in page post type), post_status is explicitly set to include both 'publish' and 'private' pages in the dropdown.

src/wp-admin/includes/meta-boxes.php — page_attributes_meta_box():

$post_type_object = get_post_type_object( $post->post_type );
if ( current_user_can( $post_type_object->cap->read_private_posts ) ) {
$dropdown_args['post_status'] = array( 'publish', 'private' );
}
src/wp-admin/includes/class-wp-posts-list-table.php — Quick Edit dropdown:

if ( current_user_can( $post_type_object->cap->read_private_posts ) ) {
$dropdown_args['post_status'] = array( 'publish', 'private' );
}
Using $post_type_object->cap->read_private_posts instead of the hardcoded 'read_private_pages' string ensures this works correctly for both the built-in page post type and any custom hierarchical post types.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props sheldorofazeroth.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.