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

Sat Feb 11 00:30:59 UTC 2017

#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 westonruter):

 Replying to [comment:29 melchoyce]:
 > @westonruter — how much of the code from Customize Snapshots can be
 adapted here?

 Quite a bit. Well, essentially this is a new view for the revisions.
 Whereas the Customize Snapshots plugin currently only shows the revisions
 in the context of the admin, the mocks here are for adding them to the
 customizer UI itself. There are REST API endpoints that expose the
 snapshots (changesets) data which we can request to then display in this
 new panel revisions view. The feature seems like a good one to build on
 top of Customize Snapshots as its feature plugin for prototyping prior to
 core merge.

 What follows is a bunch of technical details for how I think revisions
 could be implemented, but also some specifics on their behavior. There is
 overlap here with #31089.

 == Previewing a Revision ==

 For implementing what happens when you click on a previous revision: to
 preview the revision all that is needed is to sync the settings into the
 preview to trigger the selective refresh and JS-applied instant previews,
 along with any full refreshes as needed. The controls in the customizer
 will then also be populated with the previous revision's values at this
 point.

 If there are any settings contained in the loaded revision that do not
 previously exist, then this will probably necessitate a full refresh of
 the preview after the revision's settings have been populated into the
 changeset, in order to reliably ensure that the settings are all
 constructed properly. Likewise, once the user has closed the revisions
 view, the customizer would need to do a full refresh so that the sections
 and controls can be properly initialized. I should hope this refresh
 behavior would be temporary as it is certainly possible for plugins to
 listen for dynamically-created settings and create any required sections
 and controls for them dynamically. We'd need to add support for this hot
 loading of settings to widgets and nav menus first to provide theme and
 plugin authors a reference for how to implement. All this being said, most
 themes and plugins wouldn't be dynamically adding and removing settings
 with corresponding sections and controls.

 == Undo and Redo Buttons ==

 Whenever a change is made in the customizer, it would need to push onto
 some history stack which can then be traversed to undo and redo changes.
 Similar to the above with previewing revisions, this gets complicated when
 a settings gets added or removed (as in the case of creating/deleting a
 widget or nav menu item). If I remove a widget, then I'd expect clicking
 Undo to cause the widget control I just removed to restored. So it seems
 that as part of this we ''would'' need to add core support for widgets,
 nav menu items, and nav menus to dynamically add/remove their
 corresponding sections and controls when their settings are added and
 removed, respectively.

 == Revisions of a Changeset vs Published Changesets as Revisions ==
 A changeset can actually go through multiple revisions in and of itself.
 This is separate from the “revisions” recorded by successive publishing of
 customization changes (each of which is a separate changeset). 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. All of this to say, it seems like perhaps the revision list should be
 broken into two lists: the top list can be the revisions ''inside'' the
 changeset, and the bottom subsequent list can be for previously published
 changes.

 == Challenges of Reverting to a Previously-published Changeset ==

 Reverting to a revision of a changeset is easier than reverting to a
 previously-published changeset. When reverting to a revision of the
 current changeset, all this means basically is to reset the settings to
 match the state of the changeset at that revision. However, reverting to a
 previously-published changeset is more complicated/interesting. Take this
 changelog:

 1. January 1st: User changes site title to “Foo”.
 2. January 2nd: User changes site tagline.
 3. January 3rd: User changes site title to “Bar”.

 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? Each changeset only contains the settings that were modified, so as
 it stands right now we would not know what to revert the tagline to since
 it's previous value is not captured. Whenever a changeset is about to be
 published, we could capture the current value for each setting prior to
 saving. This would allow us to roll back all of the changes made to the
 site between two published changesets. The process would involve walking
 over the previous changesets to gather up a list of the previous values
 and merge them and apply them to the current changeset for previewing.

 Complication: 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?

 == Inspecting Revisions ==

 In addition to seeing the date and author for a given revision, and in
 addition to previewing the changes included in the revision, it seems that
 a user would also want to see a list of the changes contained within the
 revision so they can see what the revision entails. In the Customize
 Snapshots plugin when viewing a revision in the WP admin the user can see
 a list of all of the settings included in the changeset along with their
 values. It's not the most user friendly since the setting IDs are used as
 well as the raw setting values (e.g. an attachment ID as opposed to an
 `img` element). Alternatively to listing out all of the settings, there
 could instead be some listing of the ''controls'' that the modified
 settings are associated with. The controls with dirty settings could also
 be highlighted in some way (which ties back to there possibly being some
 per-control revert button).

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