[wp-trac] [WordPress Trac] #36738: No validation for $post_date_gmt parameter

[WordPress Trac]

#36738: No validation for $post_date_gmt parameter
-------------------------------------------------+-------------------------
 Reporter:  Latz                                 |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:
Component:  Posts, Post Types                    |     Version:  3.5
 Severity:  normal                               |  Resolution:
 Keywords:  needs-testing has-test-info good-    |     Focuses:
  first-bug                                      |
-------------------------------------------------+-------------------------

Comment (by paulbonneau):

 Hello @SirLouen,

 The two behaviors reported in @Latz's first message are still present. I
 can only reproduce them by adding code via a plugin.

 == Reproduction Report
 === Environment
 Server: Apache (Linux)
 WordPress: 6.9-alpha-60093-src
 Browser: Chrome 139.0.7258.155
 OS: Mac Os 15.4.1 (24E263)
 Theme: Twenty Twenty-Five
 Plugins: Only my custom reproduction plugin (see below)

 === Steps
 1. create a folder in `wp-content/plugins` named `36738-bug-test-
 reproducer`
 2. create a file `36738-bug-test-reproducer.php` in the previously created
 folder
 3. copy the following code in the previously created file :
 {{{#!php
 <?php
 /**
  * @package 36738-bug-test-reproducer
  * @version 1.7.2
  */
 /*
 Plugin Name: 36738 bug test reproducer
 Plugin URI:
 Description: A plugin to help reproduce the bugs in this ticket
 https://core.trac.wordpress.org/ticket/36738
 Author: Test
 Version: 1.0.0
 Author URI: #
 Text Domain: 36738-bug-test-reproducer
 */

 // Do not load directly.
 if ( ! defined( 'ABSPATH' ) ) {
     die();
 }

 add_action('admin_init', function(){
     if (filter_input(INPUT_GET, 'reproduce_1')) {
         wp_insert_post([
             'post_title' => 'test ' . uniqid(),
             'post_date' => '2025-01-23 23:00:00',
             'post_date_gmt' => 'wrong_format',
             'post_content' => ''
         ]);
     }
     if (filter_input(INPUT_GET, 'reproduce_2')) {
         wp_insert_post([
             'post_title' => 'test ' . uniqid(),
             'post_date_gmt' => 'wrong_format',
             'post_content' => ''
         ]);
     }
 });
 }}}
 4. In your WordPress admin dashboard got to Plugins and activate the
 `36738 bug test reproducer` plugin
 5. Now you can use the followings URL to reproduce @Latz cases :
  a. Case 1) : `[YOUR_WORDPRESS_URL]/wp-admin/?reproduce_1=1`
  b. Case 2) : `[YOUR_WORDPRESS_URL]/wp-admin/?reproduce_2=1`
 6. Each time an url is visited, a new post is inserted in database and
 visible in Posts

 === Analysis

 @SirLouen in your answer you said :
  ideally we should be refactoring the code to use the current version of
 wp_resolve_post_date to serve for both versions

 * I don't think we can use `wp_resolve_post_date` to serve `post_date_gmt`
 in `wp_insert_post` the same way `post_date` is served because :
  1. `wp_resolve_post_date` is explicitly waiting for a `post_date` in
 first argument and a `post_date_gmt` in the second argument;
  2. the way `post_date` and `post_date_gmt` are handled in
 `wp_insert_post` means that, the check on `post_date_gmt` with
 `wp_resolve_post_date` would need to be added before the check on
 `post_date` with the same function. Looking at the current code this would
 introduce a bit of duplication and will result in a messier
 `wp_insert_post` function.

 Before modifying the behavior of this part of the code I would like to be
 sure what is the desired behavior :
 * about @Latz case 1, if `post_date_gmt` passed to `wp_insert_post` is
 invalid, shouldn't we treat it as if it is `empty` or equal to `0000-00-00
 00:00:00` and setting it to the current datetime while not stopping the
 processing of the post data by throwing a WP_Error or returning 0 ?
 Throwing a WP_Error or returning 0 is not the current behavior, it could
 produce unexpected behavior on plugins / themes / any custom code using
 the `wp_insert_post` function.
 * If we check the `wordpress-develop` (https://github.com/WordPress
 /wordpress-develop) test cases `tests/phpunit/tests/post.php`, function
 `test_wp_resolve_post_date`, result of @Latz case 2 seems to be the
 intended behavior.

 {{{#!php
  $resolved_post_date = wp_resolve_post_date( '', $invalid_date );
  $this->assertSame( '1970-01-01 00:00:00', $resolved_post_date );
 }}}

 Plus, in the php doc block of `wp_resolve_post_date` it says :
 {{{#!php
  * For back-compat purposes in wp_insert_post, an empty post_date and an
 invalid
  * post_date_gmt will continue to return '1970-01-01 00:00:00' rather than
 false.
 }}}
 Should we go against that ?


 For information, this is the first time I've responded to a ticket and I'm
 not a native english speaker, so I apologize in advance if I make any
 mistakes regarding the rules governing these responses. Please feel free
 to correct me if necessary.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/36738#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform