Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#36485 closed defect (bug) (fixed)

Lost pending customizer settings after theme change

Reported by: kirasong's profile kirasong Owned by: westonruter's profile westonruter
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.2
Component: Customize Keywords: has-patch needs-testing
Focuses: javascript Cc:


If you make a change in the customizer, don't publish the change, then choose a different theme, your browser prompts you as to whether you want to leave the current page or not.

If you say no, the customizer hangs.
If you say yes, you lose your settings.

Video example to be attached shortly.

Attachments (1)

Customizer Loses Settings.mp4 (4.2 MB) - added by kirasong 8 years ago.

Change History (10)

#1 @kirasong
8 years ago

This is a problem in WordPress 4.4.2 (so not a regression in 4.5).
I haven't dug back to find out if it's been a problem since theme switching.

#2 @celloexpressions
8 years ago

  • Version set to 4.2

This is unfortunately expected behavior. Users need to save their changes before switching themes, and because a theme switch does in fact do a page load, if they "leave" by switching themes they'll lose their changes. I believe that customizer transactions and the ability to have draft changes could eventually lead to a better solution here, although the page load when switching themes would be very difficult to eliminate.

#3 @westonruter
8 years ago

@celloexpressions yes the loss of dirty settings is expected. However, what about the hanging behavior? I haven't experienced that before.

#4 @kirasong
8 years ago

The biggest trouble here is clicking on "Stay on this page" doesn't go back to where the user was previously, and just hangs.

If it's by design, then thinking we should warn the user and allow canceling the choice (or at least fix this issue where clicking "stay" does not "go/hang".

#5 @celloexpressions
8 years ago

The theme switcher uses the customize-loader script, which gives the illusion that there is no page load. However, what really happens is we fade in a full-screen loading indicator while waiting for a response from the serve to navigate to the new URL. However, when there are dirty settings, it has to confirm() (?) first. There isn't (or wasn't, at least) to know when a true/false value is returned from the confirm call, so we have to hide the loading indicator as soon as the confirm window is closed so that the user isn't stuck with a loading indicator preventing them from getting "back" to the customizer so that they can save there changes. When you do chose to lose changes, it still hides the loader, giving the impression of it hanging when really it's just doing the same thing it does when there are no dirty settings, but without the loading indicator.

Not a great UX, so hopefully we'll be able to improve on it at some point.

(to clarify, "stay on this page" is the previous theme, where settings are dirty; "leave" is go to the new theme, since you don't actually trigger the link until it's the last )

#6 @westonruter
8 years ago

  • Milestone changed from Awaiting Review to 4.7
  • Owner set to westonruter
  • Status changed from new to accepted

#7 @westonruter
8 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

This has been implemented in the patch for #30937.

Please test: grunt patch:

As noted there: now when you make a change to a theme_mod in theme A (like change background color to red) and then switch to another theme B and activate it instead, the next time you open theme A in the customizer for live preview the changes you made previously will be applied as your customizer state (the color will be background color will be red again). This is implementing feedback from @jorbin:

With this feature I would strongly encourage thinking in terms of user flow.

For example, "As a user, when I am live previewing and making changes to the twentyseventeen theme and then switch to live previewing the twentyten theme, I expect the customizations I made to twentyseventeen to be there the next time I live preview it"

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

8 years ago

#9 @westonruter
8 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 38810:

Customize: Implement customized state persistence with changesets.

Includes infrastructure developed in the Customize Snapshots feature plugin.


Props westonruter, valendesigns, utkarshpatel, stubgo, lgedeon, ocean90, ryankienstra, mihai2u, dlh, aaroncampbell, jonathanbardo, jorbin.
See #28721.
See #31089.
Fixes #30937.
Fixes #31517.
Fixes #30028.
Fixes #23225.
Fixes #34142.
Fixes #36485.

Note: See TracTickets for help on using tickets.