[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 mikeschinkel):

 @Otto42 Either you are not getting the point or you are destined to always
 seen things the opposite of the way I do (which, btw, makes you wrong.
 ;-p)

 '''@Otto42 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.'''

 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.

 '''@Otto42 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".'''

 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''."  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.  The fact that you want to
 think about it from a WordPress-centric focus still doesn't make it a 404.
 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.

 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.''

 So you can understand, what follows are the hooks called between
 parse_query and template_redirect for the home page on v2.9. Setting
 $is_404 to true when the URI requested was indeed "found" means that
 plugins using any of these hooks can potentially misunderstand and do
 something they shouldn't do when the URL is actually found.


 {{{
 action: parse_query
 action: pre_get_posts
 filter: pre_option_posts_per_page
 filter: option_posts_per_page
 filter: pre_option_comments_per_page
 filter: option_comments_per_page
 filter: sanitize_title
 filter: sanitize_title
 filter: sanitize_title
 filter: query
 filter: pre_option_page_for_posts
 filter: option_page_for_posts
 filter: pre_option_show_on_front
 filter: option_show_on_front
 filter: sanitize_title
 filter: posts_where
 filter: posts_join
 filter: posts_where_paged
 filter: posts_groupby
 filter: posts_join_paged
 filter: posts_orderby
 filter: posts_distinct
 filter: post_limits
 filter: posts_fields
 action: posts_selection
 filter: posts_where_request
 filter: posts_groupby_request
 filter: posts_join_request
 filter: posts_orderby_request
 filter: posts_distinct_request
 filter: posts_fields_request
 filter: post_limits_request
 filter: posts_request
 filter: query
 filter: posts_results
 filter: pre_option_sticky_posts
 filter: option_sticky_posts
 filter: the_posts
 filter: status_header
 action: wp
 action: template_redirect
 }}}


 '''@Otto42 You can't prevent bad plugins from doing bad things and
 interfering with each other.'''

 There is nothing bad about a plugin testing $is_404 and then taking an
 appropriate action.

 What '''''is''''' bad is when WordPress doesn't allow a plugin to
 correctly set the value of $is_404 so that everyone (besides @Otto42)
 misunderstands what the value implies.

 '''@Otto42 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."

 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.

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

 Too late. ;-p

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

 It's more than badly documented, it's edge cases have never been tested by
 the core devs and those like you active on the wp-hackers list; you've not
 pushed it so you haven't seen where the gaping holes are.

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