WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 months ago

#18362 assigned enhancement

Post timestamp creation should use whitelisted post statuses instead of blacklisted

Reported by: danielbachhuber Owned by: danielbachhuber
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch needs-testing editorial-flow
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 3 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 (11)

danielbachhuber3 years ago

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

comment:1 SergeyBiryukov3 years ago

  • Keywords has-patch added
  • Version set to 3.2

comment:2 danielbachhuber3 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 3 years ago by danielbachhuber (previous) (diff)

comment:3 sbressler3 years ago

  • Cc sbressler@… added

comment:4 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:5 danielbachhuber3 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.

comment:6 follow-up: SergeyBiryukov3 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].

comment:7 in reply to: ↑ 6 DrewAPicture2 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.

comment:8 nacin2 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.

comment:9 danielbachhuber15 months ago

  • Keywords editorial-flow added

comment:10 nacin3 months ago

  • Component changed from General to Post Types
Note: See TracTickets for help on using tickets.