Make WordPress Core

Opened 18 years ago

Closed 18 years ago

Last modified 17 years ago

#1837 closed defect (bug) (fixed)

Post timestamp does not correspond to publication time

Reported by: error's profile error Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.0
Component: General Keywords: timestamp post bg|has-patch bg|squashed bg|commit
Focuses: Cc:


When using the advanced editing screen, and editing a draft post, once you click Publish, the post time does not correspond to the actual time the post was published, but rather, to the most recent time that you clicked Save and Continue Editing (or Save). As a result, posts come out with a publish time of a few minutes prior to publication, and a modified time of the actual publication time.

The issue seems to be that "Edit timestamp" is checked, and so whatever happens to be in the timestamp field is used, instead of the actual time. This is useful if one wants to future publish or backdate their posts, but if one wants the post to have a publication time of the actual time it was published, then there's no way to do that.

If "Edit timestamp" is NOT checked, then on Publish, the post gets the most recently saved time, which in the case of a test post I made, was June 24th! Not exactly the desired behavior.

Attachments (3)

bug1837_drafts_shouldnt_get_auto_timestamped.diff (3.4 KB) - added by coffee2code 18 years ago.
The patch I mentioned.
functions.php.diff (584 bytes) - added by technosailor 18 years ago.
Fixes post_modified, post_modified_gmt bug
functions.php.2.diff (1.2 KB) - added by technosailor 18 years ago.

Download all attachments as: .zip

Change History (13)

#1 @error
18 years ago

I would suggest for 1837, on publish, if Edit timestamp is checked, and the timestamp is exactly the same as it was before, i.e. the user didn't change it, to ignore it and use the current time.

#2 @markjaquith
18 years ago

My suggestion:

date is BLANK until publish. On publish, date is set to current time.

#3 @coffee2code
18 years ago

  • Keywords bg|has-patch added

Just for clarification for those not clear on the nature of the bug, here's an example use case:

  1. User creates and saves a draft on 2005-10-15 12:00:00.
  2. User goes back and begins to edit the post on 2005-11-01 14:00:00.
  3. User spends 1 hour editing the post and presses "Publish".

Currently, without intervention by the user, WP automatically checks "Edit timestamp" and preloads the time fields with the time that the user began editing the post. So on publish, the post's publish date is 2005-11-01 14:00:00.

However, technically the post was published 2005-11-01 15:00:00 (recall the one hour of editing time).

If the user had instead unchecked the "Edit timestamp" field when publishing, the post would have the original, much older, date of 2005-10-15 12:00:00.

There is currently no way for the post to automatically obtain the datetime of the moment when "Publish" was pressed (given that the post was a draft and the user hadn't explicitly set the timestamp).

The solution is as markjaquith notes above, to keep the post_date blank until (a) user explicitly sets the post's timestamp, or (b) the post is published from the draft state (and (a) doesn't already apply). This entails preventing WP from ever setting the "Edit timestamp" checkbox, and for it not to show an "Existing timestamp" until one gets assigned.

I tested various usage vectors:

  • New -> Publish
  • New -> Draft -> Publish
  • New -> Draft -> Draft -> Publish
  • New -> Draft (w/ setting timestamp) -> Publish
  • New -> Draft (w/ setting timestamp) -> Draft -> Publish
  • New -> Publish -> Draft -> Publish (in which case post should retain the timestamp it was assigned during first Publish)

All variations seemed to work as expected.

But, of course, more eyes to try it out are appreciated.

A patch, bug1837_drafts_shouldnt_get_auto_timestamped.diff, is attached. It also has the advantage of trimming down touch_time().


#4 @markjaquith
18 years ago

  • Keywords bg|squashed added

You're a more persistent man than I. Nice work... it is functioning as described. I'll let a few other people bang on it.

#5 @error
18 years ago

  • Keywords bg|commit added

Patch works exactly as expected. Thanks!

#6 @matt
18 years ago

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

(In [3074]) Fixes #1837 timestamp funkiness

#7 @error
18 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening due to an error in the patch: When editing timestamp of a previously published post, post_modified is set to the edited timestamp, rather than the current time.

18 years ago

Fixes post_modified, post_modified_gmt bug

#8 @technosailor
18 years ago

  • Version changed from 1.5.2 to 2.0

Because I got tired of waiting for this to get patched, I patched it. Up until now, editing posts with explicit "modify timestamp" did not update post_modified or post_modified_gmt.

Additional: I posted a patch, then realized a flaw so I've posted a second version.

#9 @ryan
18 years ago

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

(In [3357]) Update post_modified when the post is changed. fixes #1837

#10 @(none)
17 years ago

  • Milestone 2.0 deleted

Milestone 2.0 deleted

Note: See TracTickets for help on using tickets.