Generate 404s consistently when querying something that does not exist

[markjaquith]

WordPress 404s are inconsistent. /2010/02/this-is-not-a-real-post/ will generate a 404, but ?p=99999 where there is no post ID 99999 serves a 200. There are many other examples. The result is that 200s are served, and the template for the type of thing you queried against (but failed) will be used, instead of the 404 template.

Expected:

If a query does not return posts and does not match a specified queried object, WordPress should return a 404, and use the 404 template.

Observed:

WordPress returns 200s for things like ?cat=9999999 ?p=999999 etc.

Possibly related:

#11348 #5324

[miqrogroove]

Before everything is said and done, could we consider dropping a filter in there?

[miqrogroove]

Where we left off in the IRC, we were contemplating three specific scenarios:

/category/is-emtpy/

and

/category/is-empty/page/2/

and

/category/has-one-post/page/9999999/

There has been passionate support for the first path responding 200 because it does "match a specified queried object". All three scenarios respond 200 in version 2.9. dd32 expressed a desire to respond 404 on the second and third paths.

[aaroncampbell]

+1 on responding 200 on the first one, and 404 on the second two. Anything that doesn't exist (a non-existent second page, a non-existent category, a non-existent post, etc) should 404...no matter how you get there (permalink or id)

[sivel]

related #10191

[dd32]

Related: #12256 - is_robots() + no posts = 404.

[miqrogroove]

Here's the ticket about the filter #10722

[hakre]

+1 responding 200 on empty but existing categories.

+1 for creating specs for query, those are missing. we only have the spec in the code and with every change the specs change. additionally look inside the query resolver, it's overly complex.

matt always says he like clean architecture, I do not see it in there.

[hakre]

Hmm, now after thinking about it more clearly, please ignore the first part of my last comment.

It is talking about queried objects here and I just think that a 404 response might be seen as a queried object as well. Additionally a wordpress response can contain multiple queried object, e.g. we can get a post and a single object. So this is really not simple to discuss so that everybody understands what this is about.

To make things simple I tend to say that the current implementation of the http response code (200, 404) done by core is what is to be expected. So this rather is not a bug but a feature request.

A theme itself might have bugs if it does not properly handle the repsonse according to the response code but than this would be a bug inside the theme and not inside the core.

Can the reporter who stated "WordPress 404s are inconsistent." please provide the specs against which those are inconsistent? I know there was discussion but before doing any decisions here I would like to see this properly argumented.

[hakre]

Are the 404s inconsistent between what the function is_404() returns and what the exact http response code is?

[markjaquith]

Replying to hakre:

Are the 404s inconsistent between what the function is_404() returns and what the exact http response code is?

They should be. Before sending a 404, it sets is_404.

Can the reporter who stated "WordPress 404s are inconsistent." please provide the specs against which those are inconsistent?

I outlined two cases: ?p=999 and ?cat=999 where Post 999 and Category 999 do not exist. They serve a 200, but should serve a 400. This is a difference in 404 handling between default querystring permalinks and pretty permalinks. I do not agree that this is a theme issue... it's only been handled at the theme level because our 404 handling has been inconsistent between different permalink setups.

[markjaquith]

but should serve a 400

404, rather.

[nacin]

[13315]

[miqrogroove]

Did this one break recently? If I hit /page/9999/ on a v3.1.3 site it gives me status 200 with no posts showing. I just can't remember if that was covered by the patch or not.