Handle unsaved changes in the customizer

[koopersmith]

Losing your changes is no fun.

The way I see it, we have two options:

1) Show an AYS when leaving the customizer by using an onbeforeunload handler.
2) Store unsaved customizations in a customize_data_$stylesheet option. The fact that certain customize settings persist across theme changes (options) while others don't (theme_mods and some theme-specific options) could pose a problem.

I say let's start with #1.

[jane]

I'd hate to put in an unnecessary AYS. IF it's that big a concern, would be better to bring save up to top and have blue "Save & Activate" on right, 2ndary button for "Cancel" instead of "Return to Manage Themes" on left.

[koopersmith]

Replying to jane:

I'd hate to put in an unnecessary AYS. IF it's that big a concern, would be better to bring save up to top and have blue "Save & Activate" on right, 2ndary button for "Cancel" instead of "Return to Manage Themes" on left.

I like this idea quite a bit.

From dev chat, helenyhou is going to take a stab at the patch.

[koopersmith]

In [20864]:

Theme Customizer: Change 'Return to...' link to 'Cancel' and move 'Save' button to header. props helenyhou, fixes #20692, see #19910.

[ryan]

In [20877]:

"Save & Activate", "Save & Publish" for customizer save button. Props jane. see #20692 #19910

[westonruter]

For the Widgets UI Refresh feature-as-plugin effort, a user test was put together to test integration with the Customizer. In the video at ~7:30 in, after the user had made changes to the controls and previewed them, he navigated away from the page. He forgot to hit Save & Publish, or didn't notice it there, and so he lost all of his changes. See the video here: ​http://make.wordpress.org/ui/2013/09/18/widgets-sept-16-chat-notes/#comment-23907

So if the dialog is out of the question, perhaps the Save & Publish button needs some more prominent styling when it transitions from its disabled to enabled state? Maybe an animated box-shadow or something to really get the user's attention?

/cc @helenyhou @jane

[westonruter]

Regarding:

2) Store unsaved customizations in a customize_data_$stylesheet option. The fact that certain customize settings persist across theme changes (options) while others don't (theme_mods and some theme-specific options) could pose a problem.

I just thought of an alternative to this. Now that autosave will store the drafted post in localStorage, we could do the same for settings in the customizer. Since all of the settings are stored in memory as JS objects, when leaving the customizer with unsaved changes it could store those settings in localStorage.

After having abandoned changes, when returning to the customizer, the initially-disabled "Saved" button could then swap out with an enabled "Restore" button. As soon as a change is made to a setting on the page, the Restore button would replace with the "Save & Publish" button, and the localStorage-preserved settings would be discarded. But if you hit "Restore" then the localStorage settings would be populated into the customizer settings and the button would also change out from "Restore" to "Save & Publish".

I realize that all of this dovetails nicely with the Settings Revisions plugin <​http://wordpress.org/plugins/settings-revisions/> so this functionality could be prototyped there.

Thoughts? I'm re-opening this ticket due to the findings from the user test referenced above.

[SergeyBiryukov]

This ticket was closed on a completed milestone. Please open a new one.

[westonruter]

Replying to SergeyBiryukov:

This ticket was closed on a completed milestone. Please open a new one.

Thank you. Done: #25439