404 handling optimization

[misterbisson]

With permalinks enabled, requests for non-existing URL paths result in a resource intensive select. The problem is that WP::query_posts() doesn't halt execution when WP::parse_request() 404s, causing WP_Query::get_posts() to fetch the x most recent posts. More details:  http://maisonbisson.com/blog/post/12035 .

The attached patch simply short-circuits WP::query_posts() if there's a 404. At rboren's suggestion, it also calls WP_Query::parse_query(), as some templates expect it to have run.

Honestly not sure if did_permalink is necessary, but the code works in my environments.

Please ignore or delete the first attached file, 404fix.diff.txt I'm an idiot.

Replying to misterbisson:

Please ignore or delete the first attached file, 404fix.diff.txt I'm an idiot.

Deleted. I assure you, you are not an idiot! I have met many people acting idiotic.

Will this help with ticket #5490 ?

(In [6940]) Skip main posts query if 404. Props misterbisson. fixes #5717

I haven't invested why just yet, but this change totally and completely breaks AtomPub. I wouldn't be surprised if it broke XML-RPC too. Details:

 http://intertwingly.net/projects/wordpress-atompub/report.html  http://intertwingly.net/projects/wordpress-atompub/apptestsuite.out

(In [6956]) Revert [6940]. Breaks atompub. see #5717

Reverted for now. I'll probably push this to 2.6 since it seems ripe for unintended consequences.

Revisit?

would it be valid to merely dump the $this->posts = $wpdb->get_results($this->request); call when it's a 404?

alternatively, maybe toss " and 0 = 1 " in the query to make sure the optimizer immediately returns zero rows?

I cannot get the error field to fill up when doing the query call a single time.

Please re-open with step by step instructions to reproduce if it is still relevant in trunk.