#52187 closed enhancement (fixed)
Create function to resolve a post date from post_date and post_date_gmt strings
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Posts, Post Types | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
This change breaks out the code to resolve a post date from passed post_date and post_date_gmt strings. This will allow use of the new function in other post type-specific inserts, such as found in wp_update_nav_menu_item.
By doing so, imported nav menu items can start to retain the same post date as found in their export file, improving performance of post_exists checks on existing nav menu items.
Attachments (6)
Change History (17)
#3
@
2 years ago
Should the new function have a wp_
prefix, e.g. wp_resolve_post_date()
, to avoid any potential conflicts?
#4
@
2 years ago
While testing this, I found an interesting behavior in wp_insert_post -- an empty post_date and an invalid post_date_gmt (ex. "2020-12-41 10:11:41") will result in an inserted post with a post_date of "1970-01-01 00:00:00" rather than a failure because get_date_from_gmt will always return a date.
resolve_post_date (soon to be wp_resolve_post_date) doesn't change this behavior, but unit tests surfaced it as one that was already present in 5.6.
$ wp shell wp> wp_insert_post( array( 'post_date' => '', 'post_date_gmt' => '2020-12-41 10:10:10', 'post_title' => 'Test', 'post_content' => 'Test content.', 'post_status' => 'publish' ) ); => int(11) wp> $ wp post get 11 +-----------------------+--------------------------------------+ | Field | Value | +-----------------------+--------------------------------------+ | ID | 11 | | post_author | 0 | | post_date | 1970-01-01 00:00:00 | | post_date_gmt | 0000-00-00 00:00:00 | | post_content | Test content. | | post_title | Test | | post_excerpt | | | post_status | publish | | comment_status | open | | ping_status | open | | post_password | | | post_name | test | | to_ping | | | pinged | | | post_modified | 1970-01-01 00:00:00 | | post_modified_gmt | 0000-00-00 00:00:00 | | post_content_filtered | | | post_parent | 0 | | guid | http://wp.localhost/1970/01/01/test/ | | menu_order | 0 | | post_type | post | | post_mime_type | | | comment_count | 0 | +-----------------------+--------------------------------------+ $ wp core version 5.6
Fixing this behavior would be a breaking change, as posts that would previously have been inserted with post_date "1970-01-01 00:00:00" would instead fail because of the invalid passed post_date_gmt.
@
2 years ago
Updated patch with improved test coverage of wp_insert_post and complete coverage of wp_resolve_post_date.
#7
@
2 years ago
In 82187.4.diff, I've included unit tests to cover existing behavior in wp_insert_post, as well as the output of wp_resolve_post_date. The new wp_insert_post tests should work without the patched file wp-includes/post.php to demonstrate existing behavior that should remain unaffected by the introduction of wp_resolve_post_date.
#9
@
2 years ago
- Status changed from reviewing to accepted
- Version trunk deleted
Thank you for the masses of unit tests, @jmdodd, that's always something I love to see on patches. 🙂
This is a fairly straightforward change, I'm happy with it as is. attachment:52187.5.diff has a few minor formatting tweaks, but is otherwise good to go.
Love this idea. I think automated tests for the new
resolve_post_date
function would be very helpful. It's also not obvious at first glance what is is meant byResolve the mysql-formatted post date from provided date and date GMT strings.
I wonder if a longer description might help. Perhaps:"Uses
wp_checkdate
to verify that the date passed in is a valid Gregorian-calendar date string. If no date is given, first attempt to use date_gmt otherwise fallback to useing the current time."