Opened 11 years ago
Closed 7 years ago
#25749 closed defect (bug) (wontfix)
Recent change in post type rewrite tags ('name' vs 'pagename' query vars) results in incorrect is_single()
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.7 |
Component: | Posts, Post Types | Keywords: | reporter-feedback |
Focuses: | Cc: |
Description
Changeset [25182] (see #16323) changed the rewrite tag for hierarchical post types so that the post-slug slot is mapped to the 'pagename' rather than the 'name' query var. This change has broken the is_single()
function for some hierarchical post types. See the following logic in WP_Query::parse_query()
: http://core.trac.wordpress.org/browser/tags/3.7/src/wp-includes/query.php#L1493 Because 'name' is no longer set for these items, but 'postname' is, the check falls through to line 1504, setting is_page
to true
and is_single
to false
. This seems unexpected.
Here is a simplified version of the code I'm using to register the post type. It may be that this problem only arises when passing a certain kind of rewrite
param; I'm sure you'll tell me if I'm doing it wrong :)
register_post_type( 'bp_doc', array( 'label' => __( 'BuddyPress Docs', 'bp-docs' ), 'labels' => $post_type_labels, 'public' => true, 'show_ui' => $this->show_cpt_ui(), 'hierarchical' => true, 'supports' => array( 'title', 'editor', 'revisions', 'excerpt', 'comments', 'author' ), 'query_var' => false, 'has_archive' => true, 'rewrite' => array( 'slug' => bp_docs_get_docs_slug(), 'with_front' => false ), ) );
I'm not sure I totally grasp the reasoning behind [25182], so I don't have a great suggestion for fixing this. A low-overhead fix might involve adding another else
clause in parse_query()
that catches this kind of case (where the post type is not 'page' but 'pagename' is set).
See also #25190.
Codex currently says that is_single() checks if a single post of any post type except
'attachment'
and'page'
is being displayed, and is_page() specifically checks for pages.After [25182], it looks like
is_single()
would only return true for non-hierarchical post types, andis_page()
would work for any hierarchical type. So we should either fix that or update Codex.