[wp-trac] [WordPress Trac] #38943: Customize changeset API issue with post date

[WordPress Trac]

#38943: Customize changeset API issue with post date
--------------------------+--------------------
 Reporter:  utkarshpatel  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.7
Component:  Customize     |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+--------------------
Changes (by westonruter):

 * keywords:   => needs-patch
 * milestone:  Awaiting Review => 4.7


Old description:

> In changeset when we update status with `future` with date
> {{{#!php
> wp.customize.previewer.save({status: 'future', date: '2017-01-01
> 00:00:00'})
> }}}
>
> And after that if we change status to `draft`
> {{{#!php
> wp.customize.previewer.save({status: 'draft', title: 'Add 2017
> greeting'})
> }}}
>
> It keeps `2017-01-01 00:00:00` as post_date after that.
>
> If we send `draft` request with `date` param
> {{{#!php
> wp.customize.previewer.save({status: 'draft', title: 'Add 2017 greeting',
> date: '2016-11-26 01:02:00'})
> }}}
> It gives error `not_future_date`.
>
> https://github.com/WordPress/WordPress/blob/70fc99e323e27a72280aea3b8cf2a6bd73660d54
> /wp-includes/class-wp-customize-manager.php#L2019-L2042
>
> Here in code if date is passed it assumes `future` post_status.

New description:

 In changeset when we update status with `future` with date
 {{{#!js
 wp.customize.previewer.save({status: 'future', date: '2017-01-01
 00:00:00'})
 }}}

 And after that if we change status to `draft`
 {{{#!js
 wp.customize.previewer.save({status: 'draft', title: 'Add 2017 greeting'})
 }}}

 It keeps `2017-01-01 00:00:00` as post_date after that.

 If we send `draft` request with `date` param
 {{{#!js
 wp.customize.previewer.save({status: 'draft', title: 'Add 2017 greeting',
 date: '2016-11-26 01:02:00'})
 }}}
 It gives error `not_future_date`.

 https://github.com/WordPress/WordPress/blob/70fc99e323e27a72280aea3b8cf2a6bd73660d54
 /wp-includes/class-wp-customize-manager.php#L2019-L2042

 Here in code if date is passed it assumes `future` post_status.

--

Comment:

 @utkarshpatel Is this fully a bug? Core actually allows you to create
 future-dated `draft` posts. It seems the one bug here is that after a
 changeset has been given a future date and a `future` status, that
 currently it is not facilitating the removal of the `future` status and
 future-date from the changeset, right?

 Since published changesets should serve as a timeline of published
 customizer changes, it would make sense to continue to disallow the
 supplying of the `date` for any supplied `date` that is not in the
 `future`. So I think that future dates should still be allowed when saving
 a changeset as a `draft` and not just `future`.

 So the question then is what to do about the case where a user wants to
 un-schedule a future changeset, not just remove the `future` status. If
 they change their mind and want to publish a changeset that they formerly
 had scheduled, then they need to change the status to `publish` ''and''
 reset the date to the current time. There's actually a convention in core
 for resetting the time to present and that is `0000-00-00 00:00:00`.

 If a changeset post is saved as a draft, and its date is not currently in
 the future, then its date should be reset to the current time, that is to
 `0000-00-00 00:00:00`, so that when it does get published it will have the
 current timestamp as its published time so that the changesets have the
 proper chronological order of publishing.

 I'm milestoning this for 4.7 even though we're in RC. Normally users never
 encounter this issue since core doesn't yet provide a UI for drafting and
 scheduling changesets. It would specifically be a problem in the Customize
 Snapshots feature plugin, and even then a workaround could be put in place
 via `wp_insert_post_data` filter.

 So what do you think? Do you agree with my suggestions? Do you want to
 write the patch?

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