Make WordPress Core

Opened 13 years ago

Closed 12 years ago

Last modified 10 years ago

#18114 closed defect (bug) (wontfix)

is_home erroneously returns true for custom query variables

Reported by: batmoo's profile batmoo Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2
Component: Query Keywords:
Focuses: Cc:

Description

The main query generated by wp_nav_menu has the is_home property set to true. This seems like a bug and makes it difficult to modify is_home-only queries.

Quick test:

function nav_menu_test( $query ) {
	if ( 'nav_menu_item' == $query->get( 'post_type' ) )
		var_dump( $query->is_home );
}

add_action( 'pre_get_posts', 'nav_menu_test' );

Change History (10)

#1 @solarissmoke
13 years ago

  • Summary changed from is_home erroneously returns true for nav menu queries to is_home erroneously returns true for queries on non-public post types

I believe this problem isn't just limited to nav menu queries: it happens when you limit any query to post types that are not publicly queryable (which includes nav_manu_item). The following line in query.php will always be true in such cases:

if ( !( $this->is_singular || $this->is_archive || $this->is_search || $this->is_feed || $this->is_trackback || $this->is_404 || $this->is_admin || $this->is_comments_popup || $this->is_robots ) )
			$this->is_home = true;

because none of those other vars will be true.

I think the problem is that the logic used to determine is_home() is negative, i.e., it checks all other known possibilities and if none match then it assumes we are at the home page. The problem is that with non-public post types this is not always the case.

#2 follow-up: @nacin
13 years ago

This is more or less proper behavior. is_home is the default fallback whenever you wish to add on query vars that don't otherwise change the flags.

This is the purpose of has_archive for a custom post type -- you can still query a post type when has_archive is set to false, but it'll then get is_home.

If you want to affect the front page, you'll probably want to use is_front_page, or you should be checking wp_query against the original query object (wp_the_query) to make sure you're operating on the main loop.

I'm not sure how this should be addressed, other than the way to run a query that actually discards any kind of flags from being set. I don't think I like that behavior.

#3 @solarissmoke
13 years ago

wontfix?

#4 in reply to: ↑ 2 @SergeyBiryukov
13 years ago

or you should be checking wp_query against the original query object (wp_the_query) to make sure you're operating on the main loop.

Related: #18677

#5 @nacin
13 years ago

Related: #20899. is_home() should be able to be true when is_feed() is true.

Earlier, I said "If you want to affect the front page, you'll probably want to use is_front_page" — however, this won't work due to how is_front_page() is a meta conditional that relies on the value of is_home.

#6 @wonderboymusic
12 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

But #20899

#7 @SergeyBiryukov
11 years ago

#24473 was marked as a duplicate.

#8 @SergeyBiryukov
11 years ago

#25143 was marked as a duplicate.

#9 @SergeyBiryukov
11 years ago

  • Summary changed from is_home erroneously returns true for queries on non-public post types to is_home erroneously returns true for custom query variables

#10 @mordauk
10 years ago

Looks like the patch on 25143 likely resolves this too.

Note: See TracTickets for help on using tickets.