rdsmes

I understand. A lot of hands all working toward the same end – at the same time! We all get there eventually. As for me, I’d never even looked through the bug reports before – maybe I’ll start there next time.

Kudos to Abrazell/Technosailor for the post on his blog and the patch. But we could have used your brain here on this thread over the past couple of days. And that might have saved me the trouble of digging through the code. I could have just let you do it… 🙂

At least we both ended up in the same area as the cause of the problem. Whew!

Well, just in case folks want to give it a try, the suggested patch in the bug tracking is this:

in wp-includes\functions.php, function update_post_caches (~line 1400 or so), find:
if ( !$posts )
return;

and change to:

if ( !$posts || !$posts[0]->ID )
return;

This seems to work, and serves the same purpose as my patch did.

Like I said in the other thread, I don’t visit this site that much, so I wasn’t sure how to submit bug reports, and I don’t see a link anywhere.

Ok, here’s the deal on my 404 problem, to the best of my knowledge, for any of the developer types that might want to look into this issue:

I’ve been able to reproduce the problem reliably by starting a new post, then using the ‘save and continue editing’ button. When the page is being generated to send back to my browser, here’s what happens:

1) in edit-form-advanced.php, when generating the ‘referredby’ value, the url_to_postid function is called.

2) toward the end of the function, the url_to_postid function generates a new WP_Query object.

3) the WP_Query object calls its get_posts() function.

4) After much ado, the get_posts function generates the first mySQL query through a call to $wpdb->get_results() That query IS SUCCESSFUL.

5) However, further down in the get_posts function, the resulting $this->posts array is passed to the update_post_caches function.

6) In the update_post_caches function, the $posts array is found to be non-empty. For the next mySQL query, the $post_id_array is ‘imploded’ to form the $post_id_list. But the resulting $post_id_list IS EMPTY. When this empty $post_id_list is passed as the parameter for the IN() section of the next mySQL query (comment “Get post-meta info”), mySQL complains (most likely) about the IN parameters being empty. This causes the wpdb object to print_error, and the output of that print error finds its way all the way back to the beginning of this story, in the ‘referredby’ field of the page sent back to the browser, and ultimately into the redirection URL on a ‘save’ or ‘publish’ operation. That garbage in the URL causes the 404.

I’m certainly in no position to say that there aren’t multiple problems. I can only speak to the one I’m seeing that I’ve detailed above. And in my case, the posts are actually getting posted, but the browser is redirected to never-never land. That is, in my case, pretty much just an annoyance more than a real ‘problem’.

But since what I’m seeing does seem to be some sort of misconstructed mySQL query, or at least something that is causing the database to throw up an error in complaint, that doesn’t mean that the same or a similar problem can’t or won’t crop up in other usage scenarios. I happened to figure out that I could force the one problem to occur by doing the ‘save-and-continue’, and chose to go down that road since it was very reproducible. And now I’m not sure how much further to go, since I don’t know that much about the WP inner workings with mySQL, and would hesitate to make many changes in that area since it is the heart and soul of the code.

Luckily, I’ve been doing most of the hacking on a local machine, not the machine my site is hosted on.

When looking at Apache, PHP, and MySQL versions, don’t forget to include the Zend Optimizer as well. My hosting company uses Zend, and I have seen it do funny things to parts of the older WP code.

It’s not site crippling by any means – the post mechanism still works fine, it just returns your browser to a non-existent page.

The problem is caused by a query done by the url_to_postid function call in the ‘if’ statement on line 212 of wp-admin\edit-form-advanced.php when the ‘save and continue editing’ operation is performed.

Since I’m not a mySQL expert by any stretch, I’m not sure what’s wrong with the query.