Make WordPress Core

Opened 13 years ago

Closed 20 months ago

#18362 closed enhancement (wontfix)

Post timestamp creation should use whitelisted post statuses instead of blacklisted

Reported by: danielbachhuber's profile danielbachhuber Owned by: danielbachhuber's profile danielbachhuber
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch needs-testing needs-refresh
Focuses: Cc:

Description

post_date and post_date_gmt timestamps are created when a post is published. The method should create timestamps based on whitelisted post statuses, instead of "not in a blacklist" as it exists currently.

Backstory: We have a plugin that allows users to create custom statuses. It uses the partially completed custom status API and additional code we've written. In the WordPress.org forum, a bug was reported where if they use a custom status with a post, the post time is set. Currently, they have to manually edit the timestamp of the post before publishing in order for it to be set to the proper publication date (instead of 5 days ago when they originally created it).

The origin of the problem is line #2506 in wp-includes/post.php. The post statuses to receive timestamps should be whitelisted instead of blacklisted. Because the custom statuses aren't a part of the blacklist, they receive a GMT timesteamp.

Attachments (1)

post_status.18362.1.patch (596 bytes) - added by danielbachhuber 13 years ago.
Whitelist post statuses that should receive post_date_gmt instead of blacklisting. Whitelist based on WordPress builtin statuses

Download all attachments as: .zip

Change History (13)

@danielbachhuber
13 years ago

Whitelist post statuses that should receive post_date_gmt instead of blacklisting. Whitelist based on WordPress builtin statuses

#1 @SergeyBiryukov
13 years ago

  • Keywords has-patch added
  • Version set to 3.2

#2 @danielbachhuber
13 years ago

  • Keywords needs-testing added

After working on a hacky fix further, I've discovered that there's other offending code at line #2695 in wp-includes/post.php, although I think trying to use a whitelisted array of post statuses could have negative backwards compatibility issues. Instead, it would probably be better to use get_post_stati() or some other new method.

For reference, here's what we've done as an intermediate fix.

Last edited 13 years ago by danielbachhuber (previous) (diff)

#3 @sbressler
13 years ago

  • Cc sbressler@… added

#4 @mikeschinkel
13 years ago

  • Cc mikeschinkel@… added

#5 @danielbachhuber
13 years ago

  • Owner set to danielbachhuber
  • Status changed from new to assigned

As it turns out, this commit above only solved part of it. I had to include this second bit as well: On publish, set the existing post_status to 'pending' so that line #2695 is processed properly.

#6 follow-up: @SergeyBiryukov
13 years ago

  • Version 3.2 deleted

Actually the code in question was introduced long before 3.2, so the version I've set isn't really helpful here. I've traced the origins back to [3074].

#7 in reply to: ↑ 6 @DrewAPicture
12 years ago

Replying to SergeyBiryukov:

Actually the code in question was introduced long before 3.2, so the version I've set isn't really helpful here. I've traced the origins back to [3074].

Best guess, it might be version 1.5.2 released 7/14/05.

#8 @nacin
12 years ago

  • Type changed from defect (bug) to enhancement
  • Version set to 3.0

In general, having some sort of a version tag is helpful, that way it doesn't show up on reports as needing additional triage, or being reported against trunk. Setting to 3.0 as that's when register_post_status() was introduced. Also setting to enhancement, as currently custom post statuses are not fully supported.

#9 @danielbachhuber
11 years ago

  • Keywords editorial-flow added

#10 @nacin
10 years ago

  • Component changed from General to Post Types

#11 @wonderboymusic
9 years ago

  • Keywords needs-refresh added; editorial-flow removed

#12 @desrosj
20 months ago

  • Resolution set to wontfix
  • Status changed from assigned to closed

It looks like the underlying code has changed since this was opened.

The code still uses a block list of statuses, but now dynamically gathers the list of statuses to look for using get_post_stati() to search for statuses with date_floating set to true. I think the addition of the date_floating (see [46252]/#39953) flag should solve the original problem so long as the custom status supplies a true value to override the default one of null.

With this in mind, and the fact that no one else has reported or worked on this one in 11+ years, I'm going to close this one out as a wontfix. If anyone disagrees, discussion can always continue on closed tickets, and this can be reopened if someone feels strongly enough to invest time in exploring further.

Note: See TracTickets for help on using tickets.