[wp-trac] [WordPress Trac] #25439: Prevent loss of unsaved customizer settings or provide means of restoring

[WordPress Trac]

#25439: Prevent loss of unsaved customizer settings or provide means of restoring
-------------------------+-----------------------------
 Reporter:  westonruter  |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Appearance   |    Version:  3.4
 Severity:  normal       |   Keywords:
-------------------------+-----------------------------
 This is to revisit #20692, opened by koopersmith for 3.4:

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

 In the resolution of that ticket, neither of these options were chosen.
 The `beforeunload` handler with confirmation dialog (first option) was
 discouraged, and then another suggestion was provided to just make the
 Save button more prominent so that users would not neglect to press it
 before leaving the customizer.  However, it seems the more prominent
 placement of the button is not enough.

 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,
 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

 For the 2nd option (storing unsaved settings), another solution than
 storing drafted settings in a DB option is 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 accidentally 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 the user hits "Restore" then the `localStorage` settings would be
 populated into the customizer settings and the button would also change
 out from "Restore" to "Save & Publish".

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25439>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software