WordPress.org

Make WordPress Core

Opened 11 months ago

Last modified 3 months ago

#25143 reopened defect (bug)

Appending registered query vars to home URL sets is_home to true when should be false

Reported by: mordauk Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.6
Component: Query Keywords: needs-patch needs-unit-tests
Focuses: Cc:

Description

I think I've discovered a bug with how custom query vars are handled on the home page.

Assume your site is http://yoursite.com and you have a query var called foo registered with the query_vars filter, and the front page is set to a static page.

Going to http://yoursite.com loads the front page as expected and shows the contents of the static page.

Going to http://yoursite.com/?foo=1 loads the front page but instead of showing the contents of the static page, it acts like the blog page and loads the posts list.

I haven't tracked it down fully, but I believe it's because is_home is improperly set to true in query.php. is_page is also incorrectly set to false I think.

To reproduce:

  1. Enable pretty permalinks
  2. Set the front page to a static page
  3. Register a query var:
function foo_query_vars( $vars ) {
	$vars[] = 'foo';
	return $vars;
}
add_filter( 'query_vars', 'foo_query_vars' );
  1. Go to http://yoursite.com - This will work correctly
  2. Go to http://yoursite.com/?foo=1 - This will be incorrect

Note, this only happens if the query var is registered with WP.

Change History (8)

comment:1 SergeyBiryukov11 months ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #18114 and #24473.

comment:2 follow-up: mordauk11 months ago

I don't believe this is a duplicate. I looked at both of those tickets.

Neither of those tickets correspond to the front page breaking with custom query vars, unless I missed something.

comment:3 in reply to: ↑ 2 ; follow-up: johnjamesjacoby11 months ago

  • Keywords needs-patch added
  • Milestone set to Awaiting Review
  • Resolution duplicate deleted
  • Status changed from closed to reopened

Replying to mordauk:

I don't believe this is a duplicate. I looked at both of those tickets.

Neither of those tickets correspond to the front page breaking with custom query vars, unless I missed something.

Agree. There are comments in those tickets that elude to the problem, but they don't deal with the incorrect is_front_page calculations.

This looks like a separate (and legitimate) bug to me. Setting a page as home should never result in the blog index appearing in its place.

comment:4 in reply to: ↑ 3 ; follow-up: dd3211 months ago

I would argue the current behaviour is expected at present, and is very close to the before mentioned duplicates.

Replying to johnjamesjacoby:

This looks like a separate (and legitimate) bug to me. Setting a page as home should never result in the blog index appearing in its place.

And the blog index isn't showing on the front page, The blog posts are showing on /?foo=custom, which is not the front page.

WordPress currently has no differentiation between a query var "which affects the current page" and one which "modifies the query", it assumes that all query vars will modify the query, which results in /?foo=custom not being equal to/? just the same that /?p=123 is not the same as /?.

If we had some way of detecting "This query var will not affect the query" then showing the front page on /?foo=custom would be appropriate.

comment:5 mordauk11 months ago

Is the answer to just not register the query vars then?

comment:6 in reply to: ↑ 4 johnjamesjacoby11 months ago

Replying to dd32:

I would argue the current behaviour is expected at present, and is very close to the before mentioned duplicates.

Replying to johnjamesjacoby:

This looks like a separate (and legitimate) bug to me. Setting a page as home should never result in the blog index appearing in its place.

And the blog index isn't showing on the front page, The blog posts are showing on /?foo=custom, which is not the front page.

WordPress currently has no differentiation between a query var "which affects the current page" and one which "modifies the query", it assumes that all query vars will modify the query, which results in /?foo=custom not being equal to/? just the same that /?p=123 is not the same as /?.

If we had some way of detecting "This query var will not affect the query" then showing the front page on /?foo=custom would be appropriate.

Sounds like the current behavior is out of alignment with the safe assumption of how it should work, regardless of our expectations. It should at least 404 instead and not show the is_home results when the user is not viewing the blog river.

The output shouldn't change just because a plugin added a variable to query_vars.

comment:7 mordauk11 months ago

I agree with JJJ.

comment:8 wonderboymusic3 months ago

  • Keywords needs-unit-tests added; dev-feedback removed
  • Milestone changed from Awaiting Review to Future Release

Would love a patch here

Note: See TracTickets for help on using tickets.