posts NOT Saved–several threads–no answers–huh?

With absolutely no information, I’m not sure what you expect anyone to do. Help us help you, at least give us some indication as to what’s happening or a surefire way to reproduce the problem.

After I type in the post, it doesn’t matter whether I try saving it by clicking “Save and continue editing” or “Save” or “Publish”, the post disappears. It doesn’t get saved or posted to the blog.

I re-enter post and go through same motion again and it still won’t save or publish. Usually, by the 3rd or 4th time, it will work.

Any ideas?
Thanks
Karen

When you checked your web server’s error log (as many of those other threads you probably saw suggested) what did you see — and can you share it with us here?

What did your host say when you asked them if the web server is running mod_security?

Sure. Here are a couple of the most recent–

[Wed Aug 23 16:56:45 2006] [info] [client xx.x.xx.x] (104)Connection reset by peer: client stopped connection before send mmap completed
[Wed Aug 23 16:56:46 2006] [info] [client xxx.xx.xxx.xx] (32)Broken pipe: client stopped connection before send body completed
[Wed Aug 23 16:56:47 2006] [debug] mod_rewrite.c(1644): [client xxx.xxx.xxx.xxx] mod_rewrite’s internal redirect status: 0/10.

They’re all pretty much duplicates of these.
When I just typed a quick test post and saved it, it did not save, did not post, and did not show up in the error log.

Scratching my head…
Karen

Oops, forgot to refresh error log to get current time. Still basically repeats the snippets I included above.

Karen

I am seeing the same issue after migrating my Blog to a new install running PHP 5.2.0RC3-dev and Apache 2.2.3 under Windows. I see no errors on the PHP or Apache logs. There are no errors shown on the screen either (my php.ini has the error reporting level to E_ALL). Clicking on “Save and Continue Editing” results on the following message being shown: “Filed under: Uncategorized — @”. I have verified that no records are being saved to the POSTS table.

I am currently trying with the PHP.INI settings but seeing other people having the same problems seems like it’s something else.

Any ideas?

@cdturri – are you seeing the same apache err log entries?

If so, does this happen with default permalinks?

No, I don’t see any errors on my Apache log. My permalinks are working fine.

Trying to save a new post shows this on the Apache access log:

[03/Sep/2006:21:58:12 +0100] “GET /wp-admin/post.php?action=edit&post=460 HTTP/1.1” 200 12179

460 is the next valid new post ID on my POSTS table so nothing wrong there. HTTP code 200 is OK so no problems there either. Editing and saving an existing post works with no problems though. So the issue is with new posts. Something strange is going on here…

You mentioned a server move or migration? If you check your tables, are the key fields still set to autoincrement?

Checked the POSTS table and indeed is set to auto increment.

OK, I am getting close. I enabled a full query log on MySQL and got the INSERT that WP is sending and guess what, it fails if you try to run it manually. The error is:

Field ‘pinged’ doesn’t have a default value

Checking why this is failing now…

At last… I fixed [hacked] the issue. I removed the NOT NULL attribute for the pinged and post_content_filtered fields on my POSTS table. Defore doing that I checked that I had this set to NULL on all my posts (SELECT distinct post_content_filtered FROM tb_posts t;) therefore I decided that changing the WP schema was safe. Could anyone check on their installations if they have these two fiels set as NOT NULL by default? I guess this was something that didn’t export correctly on the backup I did of my previous WP DB.

BTW, MySQL sucks! It should be possible to set the query logs fromt he client but you can only do it from the command line and you need to restart the server.

On the other side I would have expected WP to catch SQL errors. So presumably WP ignores all SQL errors then?

So presumably WP ignores all SQL errors then?

Nope.

>>So presumably WP ignores all SQL errors then?

>Nope.

The there must be a bug on the post module or it might be ignoring errors from an insert only?