[wp-trac] [WordPress Trac] #45322: Editing a draft post with wp.editPost causes its published date to be set

[WordPress Trac]

#45322: Editing a draft post with wp.editPost causes its published date to be set
--------------------------+-----------------------------
 Reporter:  redsweater    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  XML-RPC       |    Version:
 Severity:  normal        |   Keywords:  has-patch
  Focuses:                |
--------------------------+-----------------------------
 This bug exhibits the exact same behavior as #16985 did for the
 MetaWeblog-based API before wp.editPost came along. When wp.editPost was
 implemented, evidently a regression occurred causing the buggy behavior to
 rear its head again.

 The practical effect of this bug is that a draft post submitted by an API
 client, and then edited by an API client, will have its publish date
 "locked in time" to the original submission time. So for example if you
 start a draft post on May 1, and edit it for two weeks before publishing
 on May 15, the published post will have a publish date of May 1.

 To reproduce using the WordPress XMLRPC API:

 1. Create a new draft status post using wp.newPost, omitting dates from
 the submitted post. This results in a post that has a post_date_gmt that
 is zeroed out, reflecting the fact it should receive the current time when
 the post is changed from Draft to Publish.

 2. Edit that draft post using wp.editPost, again omitting any dates.

 Expected result: the draft post should still have zeroed out publish date
 (post_date_gmt).

 Actual result: the post now has a post_date_gmt value matching the
 original post_date value that was created when the draft was submitted.

 The bug appears to be rooted in the wp.editPost implementation in class-
 wp-xmlrpc-server.php. Because this method uses the existing post struct
 from the database as a baseline of all submitted content, the post_date
 value ends up being set on the struct that is passed to _insert_post. But
 _insert_post makes assumptions about client intent based on the presence
 of or absence of values on that struct. So in this case the post_date
 value on the struct is interpreted as being a client-asserted publish date
 for the post.

 I'm attaching a patch with a possible fix, which is to make a point of
 unsetting the post_date value on the struct whenever the post_date value
 is missing from the content_struct provided by the API client.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45322>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform