Me either. Stuff like this is never anything I have problems with so I never know what to advise if anything…. you might at this point post to the testers list (in self-defense, you know!)
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.
If you’re going to try that yourself, how about posting back how it goes?
Oops sorry, I did and added that fact to my previous post. Looks like it works fine, at least in my case. I would hope that a few more folks give it a try and see if it helps them.
I guess it would be nice if the support forums had a bit more insight into what was going on behind the scenes of the bug reports, but that’s a mighty task. Although it looks like this patch had just been suggested very recently, so the submitter was looking at the problem at the same time we were discussing it here.
Yeah I’d like to know since it was my patch I just submitted a bit ago. 🙂
http://www.technosailor.com/wordpress-201-posting-bug/
rdsmes – the situation here is that most of us who do “support” have a good understanding of overall stuff. Some folks will have some specialized knowledge, but whether they’re around here often enough to offer help is a crapshoot.
Volunteerism in action….
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!
I never had this problem. The only issue I have had is the pingomatic link making the post take decades to resolve. So either its timing out earlier on some of you guys, or its something else. Its important to note that not everyone is getting the same errors.
Well I had high hopes and expectations, but alas. 🙂
I tried both correction suggestions on the production server and I still get the 404 when trying to publish/save/saveandcontinue on a post with more than approx 1000 chars.
Trim the excess to under 1000 (approx) chars and the post will save.
*Problem server
Apache 1.3.34
PHP 4.4.1
MySQL 4.0.25
*Different server that doesn’t show the problem
Apache 1.3.33
PHP 4.4.0
MySQL 4.0.25
*localhost that doesn’t show the problem
Apache 2.0.55
PHP 5.1.2
MySQL 4.1.12
jeffparsons –
What’s the URL in the browser on the 404?
That looks like it should be a perfectly legit address for the ‘write post’ page for your site, doesn’t it? Have you looked in the server error log to see if the 404 error is in there? Does the 404 error page look like it comes from your site or is it a more generic Apache error page?
That’s the trick with this particular error as it surely looks like a legitimate address. It is a 404 page from my theme, not the generic Apache error page. There are no 404 errors in the cPanel error log for the site.
That’s important information, since there seems to be some confusion over WordPress-generated 404 errors, server generated 404s and browser timeouts.
Perhaps WordPress should consider using a message that give a little more info than the 404 – Not Found to help users to distinguish the difference. They all have different causes.
Here I have the same problem. But only if, before click in “publish”, I to save the post.
After click in “Publish” button I get WordPress-generated 404 error and in address bar:
http://www.rodrigomuniz.com/blog/wp-admin/%3Cdiv%20id=%5C’error%5C’%3E
%3Cdiv%20id=%5C'error%5C'%3E what it’s?
By the way, the post appears normaly, but the 404 is not cool.
