Opened 7 years ago
Last modified 4 months ago
#26798 new defect (bug)
While inserting a post some values for 'post_date' throw a PHP exception
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Date/Time | Keywords: | has-patch needs-refresh needs-unit-tests |
Focuses: | Cc: |
Description
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:
- 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.
- 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])/
Attachments (2)
Change History (7)
#2
@
7 years ago
- Component changed from Validation to Date/Time
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()
#3
@
7 years ago
- Keywords has-patch needs-testing added
- Version changed from trunk to 3.5
Introduced in r21921
#4
@
6 years ago
- Keywords needs-testing removed
Patch works as charm (WP 4.1), no errors or notices where thrown.
#5
@
4 months ago
- Keywords needs-refresh needs-unit-tests added
- Milestone set to Future Release
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.
Diff for suggested changes to fix post.php