Make WordPress Core

Opened 8 years ago

Last modified 4 years ago

#36595 new defect (bug)

can't set post_modified in wp_insert_post, becomes post_date

Reported by: gijsgg's profile gijsgg Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.0
Component: Posts, Post Types Keywords: 2nd-opinion
Focuses: Cc:


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

$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'

Attachments (2)

36595-unit-test.diff (994 bytes) - added by collinsinternet 8 years ago.
Unit Test for issue.
36597.patch (1.0 KB) - added by 5um17 8 years ago.
Patch after removing inline variables doc

Download all attachments as: .zip

Change History (12)

#1 @Latz
8 years ago

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...

8 years ago

Unit Test for issue.

#2 @swissspidy
8 years ago

  • Version changed from 4.5 to 4.2

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.

#3 @Latz
8 years ago

  • Version changed from 4.2 to 1.0


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.

Last edited 8 years ago by Latz (previous) (diff)

#4 @swissspidy
8 years ago

#36597 was marked as a duplicate.

#5 @5um17
8 years ago

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!

8 years ago

Patch after removing inline variables doc

#6 @boonebgorges
8 years ago

  • Keywords 2nd-opinion added

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.

#7 @Latz
8 years ago

Related: #36738

Last edited 8 years ago by Latz (previous) (diff)

#8 @SergeyBiryukov
4 years ago

#41227 was marked as a duplicate.

#9 @SergeyBiryukov
4 years ago

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

#10 @SergeyBiryukov
4 years ago

#49767 was marked as a duplicate.

Note: See TracTickets for help on using tickets.