[wp-trac] [WordPress Trac] #35874: XMLRPC: Draft posts are published immediately when changed to published and future-dated at once

[WordPress Trac]

#35874: XMLRPC: Draft posts are published immediately when changed to published and
future-dated at once
--------------------------+-----------------------------
 Reporter:  redsweater    |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  XML-RPC       |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 A serious issue exists since r34572, in which a post that is edited via
 the XMLRPC API, such that its post_status changes from draft to publish,
 and at the same time its post_date is changed, will have the post_date
 disregarded because of "date reset" logic within wp_update_post().

 A very negative impact of this is in a scenario where a user is confident
 that a draft post will change from draft status to future-published
 status. This behavior was reliable prior to r34572, but since that change,
 the behavior will result in an unexpectedly public, published post.

 To reproduce the bug, using an XMLRPC client app such as my MarsEdit:

 1. Publish a new draft post with no date specified.
 2. Edit the draft post, changing the publish status to "Published" AND the
 date to some future date, e.g. tomorrow.
 3. Publish the edits.

 The result is a published post with a post_date of the current time.

 Although the bug is revealed by r34572, the issue lies deeper within
 faulty logic in wp_udpate_post(). The behavior prior to r34572 in which
 new posts were always assigned a baseline post_date, prevented the logic
 in wp_update_post from ever "resetting" the date. Thus the draft post
 created in step 1 above was assigned a post_date prior to r34572, but is
 now left with an empty date.

 Subsequently, when the edits in step 2 above are made, this logic is met
 and the date is reset, even though the post being submitted for edit has
 expilicit post_date and post_date_gmt values set upon it:

 {{{
 // Drafts shouldn't be assigned a date unless explicitly done so by the
 user.
 if ( isset( $post['post_status'] ) && in_array($post['post_status'],
 array('draft', 'pending', 'auto-draft')) && empty($postarr['edit_date'])
 &&
                  ('0000-00-00 00:00:00' == $post['post_date_gmt']) )
         $clear_date = true;
 else
         $clear_date = false;
 }}}

 See how the logic in this case tests for the presence of a
 $postarr['edit_date'] value, which is as it happens always empty in the
 case of XMLRPC API edits. It seems the test for "are we editing the date"
 needs to be more nuanced than merely testing for this value.

 So it is the confluence of the following circumstnaces that lead to this
 bug:

 - A post already exists in the database
 - It does not have a specific date set
 - It has been saved as a draft, pending, or auto-draft status
 - It is not determined that its date is being edited right now

 I think the fix for this can be as simple as rethinking the logic in the
 code cited above, perhaps allowing that EITHER the presence of a an
 'edit_date' boolean, OR the presence of a non-empty post_date or
 post_date_gmt should circumvent the date reset.

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