[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

 add_filter('template_redirect', 'test' );
 function test() {
         status_header( 200 );
         echo 'Not a 404....';

 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