[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:7 mikeschinkel]:
 > How does one '''''properly''''' set $wp_query->is_404 to false?  AFAICT
 that's exactly what I did, still doesn't work.

 I can't answer that, need to read that code more to figure it out.

 > That's a dirty, ugly hack.

 Not at all! That's how PHP is expressly designed to work. The header
 function (which is what status_header is calling) is intentionally made to
 allow the code to overload headers, sending only the most recent ones.

 See http://php.net/manual/en/function.header.php

 > Basically you are letting WordPress go through and set 404 even though
 it's not a 404.

 Define "set" in that context. You're setting a header, yes, but it's not
 like you can read out those headers later or anything. Headers are write-
 only, basically.

 > That creates potential undefined cases for other plugins that may cause
 them to operate incorrectly.  Your answer is essentially "''Just let
 WordPress think everything is wrong

 Since when is a 404 "wrong"? It's a not found status code. That's not
 "wrong", it's the correct behavior if no posts to display have been found.
 You are overriding that with your plugin to say "yes, there's no posts,
 but I'm not displaying posts, so I'm going to set the header to something
 else".

 > What if some other plugin that monitors 404 has already sent data after
 the headers?

 You can't prevent bad plugins from doing bad things and interfering with
 each other. What if you put a filter into handle_404? Some plugin could
 easily going to hook to that, and then take action based on it, like
 sending output.

 > Trickery?  How else am I going to get WordPress to let me have control
 of a URL?  Trickery is reissuing a status header.

 Not trickery, design. PHP is *designed* to let you reissue status headers.
 That is *correct behavior*.

 > Reissuing a status header is not a problem per se within code you
 control. But the problem here is that WordPress is allowed to run with its
 state variables representing a state which is other than the real state.

 How is that not a real state? No posts with the given criteria were found.
 It's set the header to 404 Not Found accordingly. The fact that your
 plugin comes along and redefines that doesn't make WordPress wrong to do
 what it did.

 Think of it like this: You're using WordPress as a front end to whatever
 the heck you're outputting. But that's all you're doing, you're ignoring
 the entire posts system here. You're probably not storing data in a normal
 manner as far as WP is concerned. All you're doing is using the URL
 parser, essentially.

 WordPress uses the results of the query to set the status header. If
 you're not using the query, then setting the status header becomes your
 problem since you're not using WordPress to do it. In that case, using a
 status_header(200) call is the right thing for your plugin to do.

 > Case in point, I was just hired by a seasoned PHP developer and paid
 $300 to write a plugin that simply routes a set of URLs, nothing more!  It
 should '''''NOT''''' be this hard. I'd rather it be easy and have not made
 that money, btw.

 Tell him I would have done it for $250. :P

 It's *not* hard. It's just badly documented.

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