While inserting a post some values for 'post_date' throw a PHP exception

[mobius5150]

If you try and insert a post with a date that does not have leading zeros (eg 2012-01-8 or 2012-1-08 or 2012-1-8) a PHP error is thrown in trunk/src/wp-includes/functions.php#L4015​: A non well formed numeric value encountered due to the checkdate() call.

Minimum code to reproduce:

$post_data = array(
    'post_title' => 'some title',
    'post_content' => 'some content',
    'post_status' => 'publish',
    'post_date' => '2012-01-8 12:00:00',
);

wp_insert_post( $post_data );

Two possible solutions:

1. Get strict about date formatting: ie: require leading zeros. If a date comes in without leading zeros a WP_Error() should be returned, an error should not get thrown.
2. Allow non-leading zeros.

Either way using substr() in trunk/src/wp-includes/post.php#L2805​ is at fault.

I've attached a diff that uses a regex to parse the date using capture groups. Its much cleaner and will detect a badly formatted date and handle it gracefully. The regex does not require leading zeros. If leading zeros are required the regex should be changed to:
/^(?P<year>\d{4})-(?P<month>0[1-9]|1[012])-(?P<day>0[1-9]|[12][0-9]|3[01])/

[mobius5150]

Diff for suggested changes to fix post.php

[mobius5150]

Fixed a typo. The match array should have at least 6 elements not exactly 6.

[nacin]

Perhaps wp_checkdate() should be able to either:

• take a string and break it up on its own
• decline to pass obviously invalid values to checkdate()

[johnbillion]

Introduced in r21921

[alordiel]

Patch works as charm (WP 4.1), no errors or notices where thrown.

[desrosj]

Did some testing today on the latest trunk (currently 5.6-alpha) and this still occurs.

The patch needs a refresh, and the feedback in comment:2 needs to be explored. A unit test demonstrating the failure will also help validate any proposed fixes.

[johnregan3]

Refresh of the patch and Unit Tests

[desrosj]

THanks @johnregan3!

Could you adjust the test_wp_resolve_post_date_regex() test to use a ​data provider instead?

[johnregan3]

Replying to desrosj:

THanks @johnregan3!

Could you adjust the test_wp_resolve_post_date_regex() test to use a ​data provider instead?

Will do. Also, I'm updating my patch. I just found a bug during further testing. Apologies for that.

[johnregan3]

Update to support ISO format and use data provider for testing

[johnregan3]

@desrosj In testing, I found that the WP_REST tests use ISO formatted dates, so I added support for that. Additionally, this now handles YYYY-MM-DD dates differently from YYYY-MM-DD H:i:s so that malformed times (when included) do not cause issues. Finally, the tests are now using a data provider.

One last addition over the previous patch: I added intval() validation to wp_checkdate() to help prevent PHP Errors when invalid data is passed into it. This addresses comment:2 suggestion to "decline to pass invalid values to checkdate()"

[johnregan3]

To confirm: I've run the entire set of WP PHP Unit tests on this code.

[johnregan3]

Improved date validation & tests

[johnregan3]

I discovered some date formats were, in fact, failing (Namely RFC3339 and RSS formats), so I simplified the regex being used, and improved the validation inside of wp_checkdate().

Part of the issue with the previous patch was it added validation for time, which isn't the emphasis of wp_resolve_post_date() nor wp_checkdate(), so I removed that time validation.

[johnregan3]

Minor improvement. Label regex groups as was originally implemented by reporter.

[johnregan3]

I'm leaving this ticket alone now. Thanks for enduring the updates.