Customizer Revisions (previously reset/undo/revert)

[dgwyer]

It would be useful to be able to reset the settings to the defaults as specified in the add_setting() class method when setting up each setting.

These could be reset on a section by section basis and/or for ALL settings.

[SergeyBiryukov]

#24359 was marked as a duplicate.

[johnbillion]

Related: #9057

[westonruter]

Even beyond the reset to the initial defaults, it would be very handy to have a reset for all changes to settings since the user started editing after the customizer loaded, and also to be able to reset the changes to an individual control. As it is right now, you have to reload the entire customizer if you want to get back to a non-dirty state.

[celloexpressions]

This seems like plugin territory. The majority of users probably won't need this option, and it's just asking for users to accidentally hit it and lose their changes. It would also add a lot of UI cruft, especially if done on a granular section-by-section basis.

Color controls have this feature already, and I think any other controls where this would be necessary could implement something similar themselves. Doesn't seem particularly necessary for core things like site title & tagline, Widgets, headers/backgrounds, front page, etc.

I also think users are okay with and understand to just reload the page or close the Customizer without saving if they want to reset all changes made in the current session.

[westonruter]

As for accidentally hitting a global reset button, we can just add an AYS dialog like we've done for leaving the page when changes are not saved. If we're just talking about a single global reset button, it could slide into view as soon as any of the settings become dirty (at the same moment the Save button becomes enabled).

Something else to consider, along with a global reset and a granular control-by-control reset, is a global Undo/Redo.

I also think users are okay with and understand to just reload the page or close the Customizer without saving if they want to reset all changes made in the current session.

I don't think this is very intuitive.

[tsquez]

Personally I don't think this is plugin territory and people use more than just a color field.

The Customizer, or at least my take on it, is the actual way WordPress wants a so called "Theme Options" page to be. This is why it was built into the core. So if something is offered in core then offering a way to reset that information, especially if a theme is using a custom built customizer, is needed.

I think that with the introduction of Panels in WP 4.0 this could be something that should be looked at further. Each panel could have a reset button that sets all the sections assigned to that panel area to the default state.

Also, if you think about it, every WordPress theme that has a "Theme Options" panel has some sort of "rest" button.

[tskk]

Agree with @dgwyer, @westonruter and @tsquez
Please add this feature, With increasing use of customizer this is a MUST feature, at least a global reset.

It is much more easy to hit the reset button than to close the customizer and load it again. Also what if the user wants to undo all previous saved customizations and start afresh?

[nvartolomei]

#31075 was marked as a duplicate.

[westonruter]

BTW, for #31885 I put together a ​demo plugin that implements undo/redo specifically for widgets in the Customizer.

Here's what it looks like (see the undo/redo links next to the remove link): ​https://cloudup.com/iR8zseq2Y1G

[celloexpressions]

I think customizer revisions would probably supersede this, and provide a stronger user experience, since the reset could be done more granularly and be undone (by becoming a revision itself). See #31089.

[westonruter]

Replying to celloexpressions:

I think customizer revisions would probably supersede this, and provide a stronger user experience, since the reset could be done more granularly and be undone (by becoming a revision itself). See #31089.

Yeah, perhaps. I don't think every setting change would be captured in a transaction. If every setting change resulted in a post revision for a transaction post, there could be a ton of revisions created. I think that a transaction (#30937) would capture the state for the current session and be updated as changes are made. For a history of changes to individual settings in a customizer session, I think this should be done in the browser memory (compare with TinyMCE history manager).

[westonruter]

@melchoyce:

I really want control/command+z to work in the Customizer

[melchoyce]

customizer-revisions-i1.png​ is a first design iteration for revisions and undo/redo to the Customizer.

Future iterations could include a more granular view of each change you made within a particular revision, along with a way to draft changes and publish them later.

This would require a minor rework of the Customizer header. It'll also require some adjustments to Themes (mostly, adjusting the header on Themes to use the forward arrow instead of a button to get back to the main customizer panel), which I can mock up.

[folletto]

Nice work. I think it's a solid solution. Having the "Undo" clearly accessible makes the feature easy to use and discover, and any more advanced use is inside the history section.

I also appreciate the slimming of the theme switcher button, helping to optimize space. At some point we'll also have to review the header bar, but that's for another ticket. :D

Solid idea to have "Current version" clearly stated, as well as the instant preview of previous versions. :)

[lukecavanagh]

@melchoyce

Would displaying the author name inline to the revision date be of any help for a user?

[melchoyce]

Replying to lukecavanagh:

Would displaying the author name inline to the revision date be of any help for a user?

I think yes, in cases where more than one person has customized a site. Added that use case in customizer-revisions-i1.2.png​.

[folletto]

An aside comment after some consideration. It's a minor detail but since we're still in early stages here. I was thinking that here the left-aligned chevron to go back might not be super effective as there's no "overwhelming" feeling of hierarchy, even with the slide-in animation.

I was wondering that probably the benefits of the right chevron might not be present here, so we can just use the standard left chevron to go back.

[lukecavanagh]

@melchoyce

Cool thanks for the update.

[melchoyce]

Replying to folletto:

An aside comment after some consideration. It's a minor detail but since we're still in early stages here. I was thinking that here the left-aligned chevron to go back might not be super effective as there's no "overwhelming" feeling of hierarchy, even with the slide-in animation.

I was wondering that probably the benefits of the right chevron might not be present here, so we can just use the standard left chevron to go back.

Do you think the same should happen with Themes?

[folletto]

Do you think the same should happen with Themes?

Probably. The "inverse" direction with themes started with an assumption of an initial UI that clearly changed the page with an animation, thus there were solid visual clues and changes. Currently, just the animation is left, so it's probably worth switching back to that too. More consistency seems here a win to me.

We can review that decision later.

[karmatosed]

I think this is a solid suggestion @melchoyce, I'm excited for us to get something into prototype and testing.

[melchoyce]

Replying to folletto:

Do you think the same should happen with Themes?

Probably. The "inverse" direction with themes started with an assumption of an initial UI that clearly changed the page with an animation, thus there were solid visual clues and changes. Currently, just the animation is left, so it's probably worth switching back to that too. More consistency seems here a win to me.

We can review that decision later.

👍

@westonruter — how much of the code from Customize Snapshots can be adapted here?

[melchoyce]

Replying to karmatosed:

I think this is a solid suggestion @melchoyce, I'm excited for us to get something into prototype and testing.

I put together a static Marvel prototype: ​https://marvelapp.com/7aege0e/screen/24648401

Do you think it communicates the flow well enough to do some prototype testing with?

[karmatosed]

@melchoyce I do. Lets get that happening early next week.

[westonruter]

Replying to 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).

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

[melchoyce]

Replying to 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.

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.

I agree with keeping this small and focused on the mockup for now, with new featured introduced incrementally in future iterations. Let's try to get smaller features out the door so we don't get bogged down in the bigger details. IMO it's easier to release something focused but still a good feature in itself, then iterate to make it more full-featured. Think of it like ​releasing a skateboard.

[westonruter]

I agree with releasing incrementally, starting small. I did want to make sure to articulate how I see the problem space and provide definitions for the various aspects of what could be considered a revision in the customizer, with an eye toward what an eventual iteration could ultimately encompass.

[westonruter]

Milestoning for visibility.

[westonruter]

Moving to future release because I believe 4.9 we will focus on drafting (#39896) and scheduling (#28721) only.

[tsquez]

OMG...This is amazing...smh!

Replying to westonruter:

Moving to future release because I believe 4.9 we will focus on drafting (#39896) and scheduling (#28721) only.

[westonruter]

I just noticed that Google Sheets added named versions for revisions, which could have some insights for how we could design revisions in the Customizer: ​https://sites.google.com/site/scriptsexamples/home/announcements/named-versions-new-version-history-google-docs

[westonruter]

In 41368:

Customize: Add rightward-facing back button to Themes section header to improve navigation (since the section slides in from the left).

Also serves to prototype for an upward-facing arrow in this location for a Publish Settings section.

Props melchoyce, westonruter.
See #39896, #40278, #21666.

[westonruter]

In 41667:

Customize: Add infrastructure for trashing/reverting of unpublished changes; introduce full-screen OverlayNotification for trashing and theme install/preview.

• Introduce a new wp.customize.previewer.trash() JS API to trash the current changeset, along with logic to WP_Customize_Manager to handle deleting changeset drafts.
• Add trashing to wp.customize.state which is then used to update the UI.
• UI for trashing is pending design feedback. One possibility is to add a new trash button to Publish Settings section that invokes wp.customize.previewer.trash().
• Improve logic for managing the visibility and disabled states for publish buttons.
• Prevent attempting requestChangesetUpdate while processing and bump processing while doing save.
• Update changeset_date state only if sent in save response.
• Merge ThemesSection#loadThemePreview() into ThemesPanel#loadThemePreview().
• Remove unused autosaved state.
• Start autosaving and prompting at beforeunload after a change first happens. This is key for theme previews since even if a user did not make any changes, there were still dirty settings which would get stored in an auto-draft unexpectedly.
• Allow Notification to accept additional classes to be added to container.
• Introduce OverlayNotification and use for theme installing, previewing, and trashing. Such overlay notifications take over the entire window.

Props westonruter, celloexpressions.
See #37661, #39896, #21666, #35210.

[westonruter]

In 41694:

Customize: Add button in Publish Settings to discard unsaved changes (including drafted and scheduled), reverting Customizer to the last published state.

Props westonruter, melchoyce.
Amends [41667].
See #39896, #21666.

[celloexpressions]

Renaming to reflect the direction that the majority of discussion on this ticket moved toward. I'm also going to merge #31089 into this ticket since this one has more specific design progress.

There's a lot of good work here to explore how revision management could work in the customizer. The technical framework is largely present. There are design concepts in progress. Revision management will become even more important with the customizer adding support for block editing in WordPress 5.8.

@melchoyce do you want to continue owning this? Or could you share suggested next steps or a design path forward for someone else to pick up?

[celloexpressions]

#31089 was marked as a duplicate.

[critterverse]

Revision management will become even more important with the customizer adding support for block editing in WordPress 5.8.

Hi there! To elaborate a little further on this point, there’s been some progress recently on adding a version of the standard Gutenberg editor top bar to the Customizer Widgets editor — it will include Undo/Redo actions that work the same way as in the post editor: ​GitHub PR #31654

However, I want to caution against using this as a case for adding a similar implementation across the entire Customizer as there are a lot of open questions around whether the Widget block editor will continue to live in the Customizer.

To take a brief detour into the world of Widgets: there are currently two editor experiences, one within the Customizer and one as a standalone screen accessible from the Appearance menu. From my perspective, this is an extremely confusing user experience and we should be taking steps to consolidate these two editors into one. @celloexpressions, you had a really interesting proposal along those lines in ​this GitHub issue to unify to a single full-screen widget editor that is powered by the Customizer behind the scenes, but would ultimately appear in the Appearance menu. Here's another interesting proposal that feels like it has some conceptual overlap with this idea: ​GitHub issue #31074

I'm only getting into the open questions around the Widget editors here because I don't believe this is the most stable foundation for making larger decisions that will affect the Customizer as a whole.

Beyond that, I think the most recent comps for this proposal are going to be tricky to pick up and run with because at the moment, we are adding the Gutenberg editor top bar Undo/Redo implementation on the block-based Customizer Widgets screen. I have big questions about whether it would make sense to apply this element to other non block-based screens. Alternately, it would be confusing to see two different approaches to Undo/Redo functionality within the Customizer (a Gutenberg version for the Widget screen and one that’s similar to the comps above for other screens).

I think this proposal would benefit hugely from a larger conversation about where the Customizer is headed in the future. Should the Customizer become more "Gutenberg-like" over time to help unify the very different experiences/styles? Or will the functionalities that exist in the Customizer eventually be handled elsewhere?

TL;DR: I'm not sure it makes sense for a designer to get involved here until we have a better sense of what the near-term and long-term goals for the Customizer are, and what kind of time and resources should be allocated there.