[wp-trac] [WordPress Trac] #11312: Add 'handle_404' hook to allow plugins to route URLs
WordPress Trac
wp-trac at lists.automattic.com
Mon Jan 4 18:54:03 UTC 2010
#11312: Add 'handle_404' hook to allow plugins to route URLs
---------------------------+------------------------------------------------
Reporter: mikeschinkel | Owner: ryan
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: Rewrite Rules | Version: 2.9
Severity: normal | Keywords: needs-patch dev-feedback
---------------------------+------------------------------------------------
Comment(by Otto42):
Replying to [comment:5 mikeschinkel]:
> @Otto42 If you read the code in WordPress for handle_404() you'll find
that WordPress doesn't respect the 404 setting; even if you set it to
false in a prior hook WordPress still thinks it's smarter than you and
decides for itself if it should be 404 and when it does it sends the 404
immediate to the browser.
No, it doesn't. That's not how the PHP header() function works. Headers
are held back from being sent until there is non-header output to be sent
or until end of execution.
Until the theme gets called, WordPress should not make any output at all,
and headers, including the 404, will not be sent.
> Basically if you want to use a custom URL where the URL isn't trying to
resolve to something WordPress expects like a post or an archive or a
search then it issues a 404, period.
Not if you have properly set $wp_query->is_404 to false. Then that
handle_404() function will set a 200 header status.
Another way to work around it is simply to set your own 200 header before
producing any output. Again, headers are *not* sent until output is
produced. Check it yourself, use the headers_sent() function to determine
if the headers have been sent or not at any point in execution.
> I've created a plugin that demonstrates the problem. The plug is called
MyRouterTest and it routes a path of "mypath" using template_redirect. It
triggers a 404 and won't display on most browsers (but it will display on
Mac/Safari, go figure):
>
> * http://wordpress.pastebin.com/f1f1fcc55
>
> AFAICK, there is no way to keep this from triggering a 404 with using
some kind of ugly hack as I showed above.
>
> Or maybe I'm not seeing something obvious? If so, please educate me.
But if not please don't simply dismiss this without at least trying to
understand the problem is.
I understand your the problem, I'm just not certain how you're
experiencing it or why you need to resort to this odd trickery to do what
you want...
The most obvious solution, as I see it, would be to simply set the header
yourself.
{{{
add_filter('template_redirect', 'test' );
function test() {
status_header( 200 );
echo 'Not a 404....';
exit;
}
}}}
Even if you wanted to do it the other way and reset is_404, I'm pretty
sure parse_query is the wrong hook to use, however I confess that I don't
know the right hook to use off the top of my head.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/11312#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list