Publishing directly sets wrong date on 'post_date_gmt'

[arabek]

When publishing a new post the 'post_date_gmt' database field of 'wp_posts' table is not beeing set correctly:

mysql> select post_title, post_date, post_date_gmt, post_status from wp_posts where ID='7327';
+-------------------------+---------------------+---------------------+-------------+
| post_title              | post_date           | post_date_gmt       | post_status |
+-------------------------+---------------------+---------------------+-------------+
| GTA na PS3 opóźnione?   | 2008-04-01 15:10:41 | 0000-00-00 00:00:00 | publish     |
+-------------------------+---------------------+---------------------+-------------+

Hint: while publishing, the post is not beeing set into draft state but published directly to the blog.

I can't reproduce. The only way to publish directly with JS on is to provide content (but not title) then hit "Publish." But in that case, it provided a post_date_gmt. With JS off, providing title and content then hitting "Publish," it was also set correctly.

Need more info on how to reproduce.

actually, when publishing directly it sets the post_date_gmt right, but if the post has been saved (as draft) in the mean time, post_date_gmt is left at '0000-00-00 00:00:00'. I think the bug is in wp-includes/post.php at line 1234, where it checks for empty(post_date_gmt). When post has been saved for the first time (i.e. as draft), post_date_gmt won't be empty, but will contain '0000-00-00 00:00:00'.

So the line should read

if (empty($post_date_gmt)

'0000-00-00 00:00:00' == $post_date_gmt) {

I will post a patch for review.

I've been trying to track an error in the database, as it seemed to me, as an database bug. What seemed to be causing the problem was an empty record in the "wp_options" table. Probably a bug caused by an old plugin that has been removed already. After deleting the record (no other changes had been made to the database, aside from updating the "post_date_gmt" records by hand), new posts are being posted with a correct date.

Replying to arabek:

What seemed to be causing the problem was an empty record in the "wp_options" table. Probably a bug caused by an old plugin that has been removed already. After deleting the record (no other changes had been made to the database, aside from updating the "post_date_gmt" records by hand), new posts are being posted with a correct date.

which option was it?

Replying to techcookies:

which option was it?

As i've written before, the option was an completly empty record - both in "option_name" and "option_value", wich AFAIK should not occur, when using a clean (no plugins installed) Wordpress.

I don't know what has caused this inconsistency in the database and i won't be able to track it down any further. Sorry.

Replying to techcookies:

actually, when publishing directly it sets the post_date_gmt right, but if the post has been saved (as draft) in the mean time, post_date_gmt is left at '0000-00-00 00:00:00'. I think the bug is in wp-includes/post.php at line 1234, where it checks for empty(post_date_gmt). When post has been saved for the first time (i.e. as draft), post_date_gmt won't be empty, but will contain '0000-00-00 00:00:00'.

So the line should read

if (empty($post_date_gmt)

'0000-00-00 00:00:00' == $post_date_gmt) {

I will post a patch for review.

After posting a few times, the problem occured again. Still no clue, what is wrong, but after applying your patch to the "post.php" and editing an already published post with a wrong "post_date_gmt", the post has been updated to a correct date:

mysql> select ID, post_date, post_date_gmt from wp_posts where post_title='Pierwsze spojrzenie na nowe PS Store';
+------+---------------------+---------------------+
| ID   | post_date           | post_date_gmt       |
+------+---------------------+---------------------+
| 7407 | 2008-04-10 23:15:09 | 2008-04-10 21:15:09 |
+------+---------------------+---------------------+
1 row in set (0.01 sec)

well, the lines were put in place in Changeset 6546:  http://trac.wordpress.org/changeset/6546/trunk/wp-includes/post.php . Ryan, could you comment on this. In my opinion (i don't know if there is any other place where post_date_gmt is set) any wp2.5-installation should be giving the wrong date_gmt unless the post is published immediately without saving a draft.

Replying to arabek:

After posting a few times, the problem occured again. Still no clue, what is wrong, but after applying your patch to the "post.php" and editing an already published post with a wrong "post_date_gmt", the post has been updated to a correct date:

could you try posting a new post. This should also give the right date.

Replying to techcookies:

could you try posting a new post. This should also give the right date.

Confirmed. A new post apeared with a valid date.

Milestone 2.5.2 deleted

We have the same problem. We are using the object-cache with eaccellerator. Every date field is filled in correctly, but the post_date_gmt. The field will be corrected, if someone changes the publishing date.

This Bug is very important for us, because post_date_gmt will be used for dates in our feeds. If 0000-00-00 00:00:00 is in the db field the feed will display 1999-11-01 01:00:00.

(In [8636]) Make sure timestamps are not 0000 when publishing. Props techcookies. fixes #6527

Can we please please please get this into 2.6.1 while it's still beta?

See also: #7180

(In [8640]) Make sure timestamps are not 0000 when publishing. Props techcookies. fixes #6527 for 2.6

This problem can be reproduced in 2.9.2 by using wp_publish_post() on a previously unpublished post. I found that this problem still exists because my plugin creates new posts, saved as pending, on image uploads submitted through blog front-end. The plugin has an admin photo manager that allows admins to publish the created posts via an ajax call. This uses wp_publish_post(). The posts that are published with wp_publish_post show up in Feeds with a date of 00:00:00 0000 (or December 31, 1969).

Since this ticket was closed as fixed for a completed milestone, please open a ticket, referencing this one and describing the steps to reproduce.