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.

[danielbachhuber]

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

[danielbachhuber]

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.

[danielbachhuber]

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.

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

[DrewAPicture]

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.

[nacin]

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.

[desrosj]

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.