[wp-hackers] Should Monthly Archive Pages ever return 404?

[Mike Schinkel]

"Jess Planck" <jess at funroe.net> wrote:
> Problem is there is not a proper HTTP error code that I could 
> find dealing with your situation. Correct me if I am wrong.

What I was proposing is that the proper error code for a month where there are no posts is 200. That is a valid page IMO.

> Building a useful 404 is probably the best way to go. You 
> can make them quite complicated and keep your 404 functionality 
> in your theme.  

I addressed why that doesn't make much sense in my just prior email; I assume you sent yours before reading that one? My prior email may not change your mind but it would expect you to respond with additional justification for stuffing all the logic in one page as opposed to distributing it where the knowledge is best known.

> A 404 is important and personally I really wouldn't want to 
> promote bad habits of URI guessing by visitors.

Why is that "bad habits?" I think the only bad habits are to "guess" a URL then write a (RESTful) program that downloads the URL but breaks if the URL changes. We dicussed this topic ad-nauseum on the REST-discuss list about 2 years ago and the consensus what that guess URLs is good as long as it is humans doing it to optimize their own browsing experience.  "Guessing" URLs is really not a bad habit because the human has their own built-in error correction mechanisms. :)

Note this is my blog on the subject: http://blog.welldesignedurls.org so I've put a lot of time and thought into this subject.

BTW, in my current use-case it's not about guessing; I have a calendar with "next" and "previous" months. Why, for example, should the user get a 404 when they click "next month" where June 2009 doesn't have any posts but July 2009 does?  That makes them think my site is broken when I'd argue that it is WordPress that is broken (in this very-specific case.)

Maybe what is needed is another approach? I've taken to heart two of Peter Westwood's core principles; "WordPress is a Platform" and (something like) "Keep options to a minimum and default to the most logical."  I've interpreted the latter to mean "Options are great as part of the platform but hide as many options from the user as possible."  If I've interpreted wrong hopefully Peter will correct me.

That said it would seem that instead of hardcoding a 404 for these types of pages there should be an action/filter that determines what status code should be sent and a plugin/theme developer should be able to disable 404 generation for known patterns found in $wp_rewrite.  

Or maybe there is such an ability already built in just not one that I've been able to find?  If there is then all I need is to know it, and if there is not I'd like to propose I create a patch to add such capability.

-Mike Schinkel
http://mikeschinkel.com/