Make WordPress Core

Opened 16 years ago

Closed 14 years ago

#6527 closed defect (bug) (fixed)

Publishing directly sets wrong date on 'post_date_gmt'

Reported by: arabek's profile arabek Owned by: ryan's profile ryan
Milestone: 2.6.1 Priority: highest omg bbq
Severity: critical Version: 2.5
Component: General Keywords: has-patch tested
Focuses: Cc:

Description

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.

Attachments (1)

post.php.diff (435 bytes) - added by techcookies 16 years ago.

Download all attachments as: .zip

Change History (21)

#1 @markjaquith
16 years ago

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.

#2 follow-up: @techcookies
16 years ago

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.

#3 follow-up: @arabek
16 years ago

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.

#4 in reply to: ↑ 3 ; follow-up: @techcookies
16 years ago

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?

#5 in reply to: ↑ 4 @arabek
16 years ago

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.

#6 in reply to: ↑ 2 ; follow-up: @arabek
16 years ago

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)

#7 @techcookies
16 years ago

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.

#8 in reply to: ↑ 6 ; follow-up: @techcookies
16 years ago

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.

#9 in reply to: ↑ 8 @arabek
16 years ago

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.

#10 @arabek
16 years ago

  • Keywords has-patch tested added

#11 @ryan
16 years ago

  • Owner changed from anonymous to ryan

#12 @ryan
16 years ago

  • Milestone changed from 2.5.2 to 2.9

Milestone 2.5.2 deleted

#13 @hetjens
16 years ago

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.

#14 @ryan
16 years ago

  • Milestone changed from 2.9 to 2.7

#15 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#16 @dougal
16 years ago

  • Cc dougal ryan added
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

See also: #7180

#17 @ryan
16 years ago

  • Milestone changed from 2.7 to 2.6.1

#18 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#19 @bennebw
14 years ago

  • Cc bennebw added
  • Priority changed from highest omg bbq to normal
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.5 to 2.9.2

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).

#20 @nacin
14 years ago

  • Priority changed from normal to highest omg bbq
  • Resolution set to fixed
  • Status changed from reopened to closed
  • Version changed from 2.9.2 to 2.5

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

Note: See TracTickets for help on using tickets.