Post timestamp creation should use whitelisted post statuses instead of blacklisted

[danielbachhuber]

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.

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

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.

Later: As it turns out, the code 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 identified above is processed properly.

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.

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

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.

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.