WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 3 days ago

#21666 assigned feature request

Customizer reset/undo/revert

Reported by: dgwyer Owned by: melchoyce
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4.2
Component: Customize Keywords: needs-patch ux-feedback
Focuses: ui Cc:

Description

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.

Attachments (2)

customizer-revisions-i1.png (320.0 KB) - added by melchoyce 12 months ago.
customizer-revisions-i1.2.png (346.9 KB) - added by melchoyce 12 months ago.

Download all attachments as: .zip

Change History (52)

#1 @dgwyer
5 years ago

  • Component changed from General to Themes

#2 @SergeyBiryukov
5 years ago

  • Component changed from Themes to Appearance

#3 @dgwyer
5 years ago

  • Version set to 3.4.2

#4 @mercime
5 years ago

  • Cc mercijavier@… added

#5 @SergeyBiryukov
5 years ago

#24359 was marked as a duplicate.

#7 @westonruter
4 years ago

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.

#8 @celloexpressions
4 years ago

  • Focuses ui added
  • Keywords 2nd-opinion added

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.

#9 @westonruter
4 years ago

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.

#10 @tsquez
3 years ago

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.

#11 @tskk
3 years ago

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?

#12 @nvartolomei
3 years ago

#31075 was marked as a duplicate.

#13 @westonruter
3 years ago

  • Keywords needs-patch added; 2nd-opinion removed
  • Milestone changed from Awaiting Review to Future Release
  • Summary changed from Theme customizer reset to Customizer reset/undo/revert

#14 @westonruter
3 years ago

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

#15 follow-up: @celloexpressions
22 months ago

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.

#16 in reply to: ↑ 15 @westonruter
21 months ago

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

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


12 months ago

#18 @westonruter
12 months ago

@melchoyce:

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

#19 @westonruter
12 months ago

  • Keywords ux-feedback added
  • Owner set to melchoyce
  • Status changed from new to assigned

#20 follow-up: @melchoyce
12 months ago

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.

#21 in reply to: ↑ 20 @folletto
12 months ago

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. :)

#22 follow-up: @lukecavanagh
12 months ago

@melchoyce

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

#23 in reply to: ↑ 22 ; follow-up: @melchoyce
12 months ago

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.

#24 follow-up: @folletto
12 months ago

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.

#25 in reply to: ↑ 23 @lukecavanagh
12 months ago

@melchoyce

Cool thanks for the update.

#26 in reply to: ↑ 24 @melchoyce
12 months ago

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?

#27 follow-up: @folletto
12 months ago

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.

#28 follow-up: @karmatosed
12 months ago

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

#29 in reply to: ↑ 27 ; follow-up: @melchoyce
12 months ago

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?

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


12 months ago

#31 in reply to: ↑ 28 @melchoyce
12 months ago

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?

#32 @karmatosed
12 months ago

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

#33 in reply to: ↑ 29 @westonruter
12 months ago

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

#34 follow-up: @folletto
11 months ago

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.

#35 in reply to: ↑ 34 @melchoyce
11 months ago

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.

Last edited 11 months ago by melchoyce (previous) (diff)

#36 @westonruter
11 months ago

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.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


10 months ago

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


10 months ago

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


7 months ago

#40 @westonruter
7 months ago

  • Milestone changed from Future Release to 4.9

Milestoning for visibility.

#41 follow-up: @westonruter
6 months ago

  • Milestone changed from 4.9 to Future Release

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

#42 in reply to: ↑ 41 @tsquez
6 months ago

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.

#43 @westonruter
5 months ago

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

#44 @westonruter
4 months ago

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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


4 months ago

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


4 months ago

#47 @westonruter
4 months ago

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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


4 months ago

#49 @westonruter
4 months ago

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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


3 days ago

Note: See TracTickets for help on using tickets.