[wp-trac] [WordPress Trac] #21666: Customizer reset/undo/revert

[WordPress Trac]

#21666: Customizer reset/undo/revert
-------------------------------------+-----------------------------
 Reporter:  dgwyer                   |       Owner:  melchoyce
     Type:  feature request          |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Customize                |     Version:  3.4.2
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch ux-feedback  |     Focuses:  ui
-------------------------------------+-----------------------------

Comment (by folletto):

 > In the case of revisions inside a changeset, consider where a user
 starts making changes and then saves a draft or sends the URL off for
 someone else to iterate on; each time a user saves a draft of the
 changeset, a new revision can be made. These revisions are for changes
 that haven't been published yet, whereas the contents of previously
 published changesets are.

 This feels a lot to expose in a general UI. Can't we start with the design
 above, and then leave the sub-changeset (revisions inside a changeset) for
 plugins?

 If it's possible, we can review the behaviour of the sharing URL in this
 context while we iterate.

 > Now, if the user clicks the changeset revision for January 1st, my
 assumption is that this will restore the site title of “Foo”. However,
 will it also include a revert of the change made to the tagline on January
 2nd?

 Yes, that's what I would assume being the expected behaviour: everything
 gets rolled back to a specific point in time.

 I'm not sure what's the best tech approach here to the issue you raise
 tho.



 > What about when a user makes a change to the tagline outside of the
 customizer? In that case the tagline would not be referenced in any
 changeset, and reverting to the changeset on the 1st would only rollback
 the site title. Would this be expected behavior?

 Well spotted. This is a tricky one. In an ideal scenario every change
 should be logged in the history, regardless of the source of the change...
 as I can imagine plugins to interfere to this issue too if the history
 isn't recorded at a lower level.

 I think this isn't completely avoidable unless there's that kind of lower
 level architecture in place, however... we do preview the site before
 publishing a revert, so at the very least the user would se that "not
 everything" got rolled back. It's not ideal, but at the very least
 shouldn't be a surprise (unless the change is on a separate page or
 invisible part of the page).

 > Inspecting Revisions

 I agree this could be nice, but I'd probably mirror the question above on
 being maybe plugin territory, or at the very least can be explored in an
 incremental step of this feature.

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