Opened 3 years ago
Closed 2 years ago
#39275 closed enhancement (fixed)
Improve wp.customize.previewer.save() for changesets.
Reported by: | sayedwp | Owned by: | sayedwp |
---|---|---|---|
Milestone: | 4.9 | Priority: | high |
Severity: | normal | Version: | 4.7 |
Component: | Customize | Keywords: | has-patch |
Focuses: | javascript | Cc: | |
PR Number: |
Description (last modified by )
If you do not pass any status in wp.customize.previewer.save()
the changeset status becomes published because the default changesetStatus
is publish
in core, which compels you to pass a status if you want to save the changeset with any other statuses like draft/pending/future
however that eventually creates a revision. So if you do not want to create revisions there is no option except hacking the customize_save
ajax request probably with $.ajaxPrefilter
.
So I think if we do not pass any status in wp.customize.previewer.save()
it should just save the changeset to the previous status set.
Also it would be nice if it had a param like skip_revision
which skips creating new revision.
Attachments (2)
Change History (17)
@
3 years ago
Adds additional param skip_revision
for wp.customize.previewer.save
. By default it will store revision.
#1
@
3 years ago
- Description modified (diff)
- Summary changed from Improve wp.customize.previwer.save() for changesets. to Improve wp.customize.previewer.save() for changesets.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
2 years ago
#4
@
2 years ago
- Milestone changed from 4.8 to 4.8.1
Per yesterday's bug scrub, we're going to punt this to 4.8.1.
This ticket was mentioned in Slack in #core-customize by jeffpaul. View the logs.
2 years ago
#8
@
2 years ago
- Owner changed from westonruter to sayedwp
- Status changed from accepted to assigned
@sayedwp What are the scenarios where wp.customize.previewer.save()
would need to be called directly? Are the use cases not now actually better served by calling wp.customize.requestChangesetUpdate()
if no revision is desired to be made?
See also: https://github.com/xwp/wordpress-develop/pull/258/commits/dfe16326127c9007d903d60322d285d509003c4b
In regards to 39275_version2.patch, a couple bits of feedback:
filter_var()
isn't used in core, so we'd to use an alternative.- This logic seems backwards:
$allow_revision = (bool) $args['skip_revision'];
. If we're skipping should this not mean a revision is disallowed?
But if this change isn't actually required, then no need to update the patch.
#9
@
2 years ago
- Priority changed from normal to high
Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.
#10
@
2 years ago
@westonruter One scenario is when only the changeset post title or date needs to be updated without creating revisions even if there are no other changes. I think wp.customize.requestChangesetUpdate()
would short circuit if there are no dirty settings. We had this problem when we were auto saving the changeset title / date in snapshot plugin.
#11
@
2 years ago
Updating the title would be supported by this proposed change here: https://github.com/xwp/wordpress-develop/pull/256/commits/242eafa
It allows a title
or date
to be supplied.
#13
@
2 years ago
It's not ideal that there are two separate APIs here that essentially do the same thing, but they do have different enough use cases that make them useful in their own right. We'll need to revisit these entirely to create a new common underlying API call that reaches out to the upcoming Customizer endpoints when we get to it.
Without using additional param. If status is not passed it will not store revision.