[wp-trac] [WordPress Trac] #11312: Add 'handle_404' hook to allow plugins to route URLs

[WordPress Trac]

#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:9 mikeschinkel]:
 > Yes, PHP allows you to call header() multiple times to set the same
 header, I'm not disputing that.  What I'm saying is that in the context of
 WordPress using it is a bandaid and is potentially harmful because you are
 not addressing the root issue, you are sweeping the dirt under the carpet.

 See, I would disagree with that notion. It's a layering mechanism.
 WordPress sets what it thinks the header should be (and it's right, BTW),
 then your plugin corrects it if/when it needs to do so.

 Adding a filter to let it check to see if any plugins want to set the
 header is a silly and unnecessary step. Your plugin is setting the header
 either way, yesno? Except using a filter mechanism is a lot more code to
 execute to achieve the exact same result.

 Overriding the header has exactly the same result as using a filter to set
 it to what you want in the first place.

 > You are conflating to issues that should be separate. 404 is a well
 known status code for HTTP that tells the browser that the URI requested
 was not found by the server.  It is ''not'' the status code that means
 "''Wordpress' posts not found''."

 No, you are conflating the issues here by combining the notion of the URL
 with the router and the query. They are separate and behave separately.

 WordPress is returning a 404 in this case because *it doesn't know about
 your URL*. You've told it to recognize your URl case and to set variables
 based on that. In a normal case, these variables would impact the query to
 return something to display. They didn't, it found no posts/pages/anything
 of any sort to display. So it set a 404 and would, in normal conditions,
 return the 404.php template file.

 However, you seem to think that because you told it about the URL, that it
 shouldn't set the header. What you're missing is the fact that the URL is
 not the query and it is also not the router, no matter how much you want
 to combine all these things.

 URLs get parsed into variables. Variables can control the query
 parameters. The results of the query set the headers and determine the
 template to use. This is the way things move through the system, and
 you're not doing it that way. You're wanting to bypass whole sections of
 this system without replacing what that section does completely.

 I tell you that it is proper for the query to set headers because the
 query is what retrieves the content that the rest of the system is
 designed to display. If there is no content, then setting s 404 is
 appropriate. If, however, you want to replace the query and put your own
 content there, then you need to adjust the headers accordingly.

 Yes, you say that the HTTP header codes are not made for WordPress. But in
 actual fact, the HTTP header codes are not made for anything in
 particular. They are available to be mapped to whatever conditions are
 appropriate, and WordPress maps "no content" to a "404". This is not an
 invalid mapping.


 > By setting 404 '''on a valid URL''' you are letting WordPress maintain
 the notion that the URI requested was not found when in this case it most
 certainly was.

 No, the URL was not found until your plugin made it have meaning.
 Unfortunately, your plugin is incomplete until you have it set the header
 as well.

 > It is ''dangerous'' to have WordPress think it is a 404 and tell plugins
 it is a 404 when in fact is '''not''' a 404.

 No, because if your plugin is not there, it is still a 404. It's only not
 a 404 when your plugin changes that fact.

 > If the property were instead ''is_posts_found'' then I'd agree with you;
 no posts were found. No, 404 is not that, it is "URI requested not found"
 and that is invalid when the the URI matches a pattern we want matched.
 Setting it to 404 internally is just ''wrong.''

 Your opinion is not the opinion of everybody else, nor is it "right"
 because you want it to be so. "URI requested not found" is a valid
 interpretation because the Resource that is being requested (post content)
 was not found by WordPress. Unless you change that fact, it remains valid.

 A URI is not a URL. The distinction is important.

 > That's Reductio Ad Absurdum. As you said, you can't prevent bad plugins
 from doing bad things. I'm not sure this would be bad but even so that's
 like saying we should use hooks because someone might misuse hooks;
 clearly an absurd position.

 No, it's not an absurd argument. You're saying that you need a hook
 because you can't override the 404. But you *can* override the 404. You
 can even detect when the 404 condition holds with a call to is_404().

 In fact, all you really have to do is something like this in your
 template_redirect function:

 {{{

 if (i_have_something_to_display()) {
 if (is_404()) { status_header(200); } // I have something to display, this
 ain't a 404 any more!
 display_something();
 }

 }}}

 Simple as that, really. It's a 404 *until* you have something to display,
 at which point you can change it to a non-404 code.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11312#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software