WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#38943 closed defect (bug) (fixed)

Customize changeset API issue with post date

Reported by: utkarshpatel Owned by: westonruter
Milestone: 4.7 Priority: low
Severity: normal Version: 4.7
Component: Customize Keywords: has-patch commit dev-reviewed
Focuses: Cc:

Description (last modified by westonruter)

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.

Change History (16)

#1 @westonruter
13 months ago

  • Description modified (diff)
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.7

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

#2 @westonruter
13 months ago

  • Priority changed from normal to low

#3 @utkarshpatel
13 months ago

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

#4 @westonruter
13 months ago

  • Keywords needs-unit-tests added

#5 @westonruter
13 months ago

  • Owner set to utkarshpatel
  • Status changed from new to assigned

#6 @utkarshpatel
13 months ago

  • Keywords needs-patch needs-unit-tests removed

#7 @westonruter
13 months ago

  • Keywords has-patch added

#8 @westonruter
13 months ago

  • Keywords needs-testing added

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.

#9 @sayedwp
13 months ago

Tested the patch, looks good to me +1

#10 @westonruter
13 months ago

  • Keywords commit dev-feedback added; needs-testing removed

This ticket was mentioned in Slack in #core by westonruter. View the logs.


13 months ago

This ticket was mentioned in Slack in #core by helen. View the logs.


13 months ago

#13 @westonruter
13 months ago

  • Owner changed from utkarshpatel to westonruter
  • Status changed from assigned to accepted

#14 @helen
13 months ago

  • Keywords dev-reviewed added; dev-feedback removed

#15 @westonruter
13 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#16 @westonruter
13 months ago

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.

Note: See TracTickets for help on using tickets.