Allow filtering of whether or not 404 should be handled.

[prettyboymp]

There are certain situations where a user may not want the page to always 404 when there are no posts for the given permalink. IE, author pages, dates, etc. There should be a filter available to allow the 404 handling to be bypassed.

[miqrogroove]

How about situations where a template finds no posts and wants to force a 404?

[prettyboymp]

Replying to miqrogroove:

How about situations where a template finds no posts and wants to force a 404?

The template can issue a 404 at anytime as long as no content has been sent yet. This patch just allows plugins to keep a 404 from being thrown before the template or plugin has had a chance to handle it how it wants.

[hakre]

Since the last patch was created the function did change. I placed the filter now as it was intended in the old patch.

Additionally it was possible to remove duplicate code.

As an improvement compared to the old patch, now, if 404 was de-filtered, 200 is given if !is_404() which was the standard behaviour of the function in pre-filter times.

[Denis-de-Bernardy]

doesn't WP already return a 200 code when no posts are found for a valid url?

[prettyboymp]

Only if its a tag, category, author, or other queried object. While that covers most of the situations, it doesn't cover all of them, which is why the filter is needed.

The specific instance I needed this was while using a custom post_type of calendar_event where the events for a month were displayed with a permalink structure of /events/year/month/. I didn't want a month returning a 404 just because their weren't any events scheduled for the month yet. My only work around was to falsely set is_category as true on 'posts_selection' then remove it on 'template_redirect'.

[Denis-de-Bernardy]

you could also hook into the wp hook or during query parsing, too. but yeah, a new filter makes more sense.

[prettyboymp]

fixed undefined $handle_404 var

[prettyboymp]

fixed logic differences

[chrisscott]

Tested this against r13305 and it works. Used the following to test:

add_filter('handle_404', 'no_404');  function no_404(){return false;}

[nacin]

Looks like a duplicate of #11312, which was closed as invalid.

[prettyboymp]

To the arguments against the filter in #11312:

The solution of setting $is_404 to false doesn't work since the handle_404 function also checks post count.

Adding a hook to template_redirect to override the 404 status header would also overwriting the no-cache headers that were set. Which, I understand its a simple thing to override those too, but now you have several headers being messed with at different points in the program flow, which is just opening a bigger gap for conflicts.

[markjaquith]

That sounds like a good argument, prettyboymp. I just made a change in the 404 logic yesterday... seems good to have one place where a plugin can hook in and say "WP, don't send a 404."

[Denis-de-Bernardy]

I attached an alternative patch. (didn't like the logic in the first much...)

[nacin]

Punting due to feature freeze.

[nacin]

#21978 was marked as a duplicate.

[nacin]

#21978 was marked as a duplicate.

[ethitter]

refreshed for 3.4

[ocean90]

10722.5.patch​ introduces a filter pre_handle_404 to allow short-circuiting the status handling.

In ​GlotPress we don't use the main query at all. Therefore, if you have no published posts each request gets handled as a 404 error.

Thoughts?

[ocean90]

In 36629:

In WP::handle_404() introduce a filter pre_handle_404 to short-circuit default header status handling.

This comes handy if you use WordPress without posts, means $wp_query contains no results.

Props prettyboymp, hakre, prettyboymp, Denis-de-Bernardy, ethitter, ocean90.
Fixes #10722.

[waisir]

​https://wordpress.stackexchange.com/questions/203019/custom-endpoint-gives-404-header

<?php
add_rewrite_endpoint( 'my-page', EP_PERMALINK );
add_rewrite_rule( '^store/checkout', 'index.php?my-page=mtc-checkout', 'top' );