can't set post_modified in wp_insert_post, becomes post_date

[gijsgg]

When manually instering a post, post_modified isn't working, it becomes the post_date

<?php
$wp_test = array(
  'post_title'        => 'test',
  'post_content'      => 'test',
  'post_status'       => 'publish',
  'post_type'         => 'test',
  'post_author'       => 1,
  'post_date'         => '2015-01-22 22:00:12',
  'post_modified'     => '2016-04-18 12:12:12',
  'comment_status'    => 'closed'
);
wp_insert_post( $wp_test );

outcome: post_modified = '2015-01-22 22:00:12'

[Latz]

Let's take a look at the code ( wp-includes/post.php, line 3192)

function wp_insert_post() {

[...]

if ( $update || '0000-00-00 00:00:00' == $post_date ) {
		$post_modified     = current_time( 'mysql' );
		$post_modified_gmt = current_time( 'mysql', 1 );
	} else {
		$post_modified     = $post_date;
		$post_modified_gmt = $post_date_gmt;
	}

Well it seems, that the $post_modified_date defined in the parameter array isn't used at all. The logic looks like this:

If the post is going to be updated ($update == true) or the $post_date isn't set (0000-00-00 00:00:00, evaluated some lines above) the current time is used; otherwise the $post_modified_date is set to the current time.

According to the phpdoc this isn't the desired behaviour but the one you expected:

 *     @type string $post_modified         The date when the post was last modified. Default is
 *                                         the current time.
 *     @type string $post_modified_gmt     The date when the post was last modified in the GMT
 *                                         timezone. Default is the current time.

I'm going to work on a patch if there aren't any other opinions...

[collinsinternet]

Unit Test for issue.

[swissspidy]

Was just commenting, but Latz beat me to it.

It feels like post_modified is more of an internal field, and not something you should be able to set manually. At least I can't think of a reason to do that and that's how it's always worked (since version 1.0, basically).

The parameter was documented as part of #31359.

[Latz]

@swisspidy

That brings up the question if the parameter is used anywhere in core and if it isn't, if it wouldn't be a good idea to remove it from the code.

I have used wp_insert_post myself in a plugin and had expected that it would be set to the parameters date, so I didn't even checked it. Now I need to change the code and hack it into the database directly which isn't best practice at all (Update: Of course I don't have to write it directly into the DB, there's a filter that can be used. Details follow.)

Real world case: Import posts from another CMS.

tldr: Remove the parameter or fix the code.

[swissspidy]

#36597 was marked as a duplicate.

[5um17]

IMHO post_modified is not something very frequently use metadata, we just need to update the documentation. Moreover, as @Latz mentioned modification date can be set using wp_insert_post_data filter!

[5um17]

Patch after removing inline variables doc

[boonebgorges]

Real world case: Import posts from another CMS.

I have run into this before myself. wp_insert_post() is a low-level function, and should allow all values to be changed. I agree that there's no need to support the parameter in wrapper functions, and in fact perhaps the parameter should be disallowed from passing through from wrapper functions (unset( $params['post_modified']).

IMO, the only concern with making this change is that it's technically a compatibility break. Anyone currently passing post_modified to wp_insert_post() is being stymied, but on update to 4.6, the "fix" would make their code work, in ways that may be unexpected. This seems to me like a straightforward case of fixing a bug, but it's worth mentioning in any case.

[Latz]

Related: #36738

[SergeyBiryukov]

#41227 was marked as a duplicate.

[SergeyBiryukov]

Note: 41227.2.patch:ticket:41227​ has another unit test.

[SergeyBiryukov]

#49767 was marked as a duplicate.