#38943 closed defect (bug) (fixed)
Customize changeset API issue with post date
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.7 | Priority: | low |
Severity: | normal | Version: | 4.7 |
Component: | Customize | Keywords: | has-patch commit dev-reviewed |
Focuses: | Cc: |
Description (last modified by )
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
.
Here in code if date is passed it assumes future
post_status.
Change History (16)
#1
@
7 years ago
- Description modified (diff)
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 4.7
#3
@
7 years 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.
#6
@
7 years ago
- Keywords needs-patch needs-unit-tests removed
@westonruter Can you check https://github.com/xwp/wordpress-develop/pull/208/files ?
#8
@
7 years 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.
@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 afuture
status, that currently it is not facilitating the removal of thefuture
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 supplieddate
that is not in thefuture
. So I think that future dates should still be allowed when saving a changeset as adraft
and not justfuture
.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 topublish
and reset the date to the current time. There's actually a convention in core for resetting the time to present and that is0000-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?