Customize changeset API issue with post date

[utkarshpatel]

In changeset when we update status with future with date

wp.customize.previewer.save({status: 'future', date: '2017-01-01 00:00:00'})

And after that if we change status to draft

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

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.

[westonruter]

@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?

[utkarshpatel]

@westonruter

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?

Yes right.

Yes, I agree with your suggestions. Yep, I will create a patch and submit.

[utkarshpatel]

@westonruter Can you check ​https://github.com/xwp/wordpress-develop/pull/208/files ?

[westonruter]

The patch at ​https://github.com/xwp/wordpress-develop/pull/208 is looking good. It needs some more testing and eyes before I want +1 commit. I also want to add some more unit tests.

[sayedwp]

Tested the patch, looks good to me +1

[westonruter]

In 39409:

Customize: Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time.

• Also moves checks from customize_save Ajax handler to the underlying WP_Customize_Manager::save_changeset_post() call which plugins may invoke directly.
• Ensures that customize_save_response filter is always passed an array, with error code available as code.

Props utkarshpatel, westonruter, sayedwp.
See #30937.
Fixes #38943.

[westonruter]

In 39410:

Customize: Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time.

• Also moves checks from customize_save Ajax handler to the underlying WP_Customize_Manager::save_changeset_post() call which plugins may invoke directly.
• Ensures that customize_save_response filter is always passed an array, with error code available as code.

Props utkarshpatel, westonruter, sayedwp.
Merges [39409] into 4.7 branch.
See #30937.
Fixes #38943 for 4.7.