Recent change in post type rewrite tags ('name' vs 'pagename' query vars) results in incorrect is_single()
|Reported by:||boonebgorges||Owned by:|
|Component:||Posts, Post Types||Keywords:||reporter-feedback|
Changeset  (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 , 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.