Make WordPress Core

Opened 6 years ago

Closed 4 years ago

#30529 closed defect (bug) (duplicate)

Customizer: Settings with type 'option' not saved before refresh

Reported by: jaspermdegroot Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.0.1
Component: Customize Keywords:
Focuses: administration Cc:


Steps to reproduce:

Customizer setting in my theme functions.php:

$wp_customize->add_setting( 'theme_name_options[example_option]', array(
    'default'    => 'example_default',
    'type'       => 'option',
    'transport'  => 'postMessage',
 ) );

$wp_customize->add_control( new WP_Customize_Image_Control( $wp_customize, 'example_option_control', array(
    'label'      => __( 'Set example option', 'theme_name' ),
    'section'    => 'section_that_has_been_added',
    'settings'   => 'theme_name_options[example_option]',
) ) );

Change the example_option setting in the customizer panel (my JS live preview works as expected).

Then, without "Save & Publish" first, change another setting that uses transport 'refresh'. For example, change the site title.

The result is that the new value for example_option is not saved, and the preview shows the last saved or default value again after the refresh. The control for example_option will still show the new selected value though.

If I do the same, but with the default type 'theme_mod' (still using transport 'postMessage'), the setting is saved before the refresh. I would expect that the behaviour is the same for both types.

I tested with 4.0.1 and 4.1 beta 1.

Attachments (4)

functions.php (5.0 KB) - added by jaspermdegroot 6 years ago.
Test theme functions
live-preview.js (1.4 KB) - added by jaspermdegroot 6 years ago.
Test theme script
index.php (2.4 KB) - added by jaspermdegroot 6 years ago.
Test theme index
style.css (471 bytes) - added by jaspermdegroot 6 years ago.
Test theme style

Download all attachments as: .zip

Change History (11)

#1 @westonruter
6 years ago

  • Keywords reporter-feedback added

Thanks for the report, jaspermdegroot.

Are you observing this same behavior in 3.9? Also, I assume your $wp_customize calls are inside of some customize_register action callback function, yes?

Could you also include the JS you're using to apply the changes transported by postMessage, and also the PHP you're using to read the setting when a refresh happens?

#2 @jaspermdegroot
6 years ago

Thanks for your reply @westonruter and sorry for not including all the code. My $wp_customize calls are indeed inside of a customize_register action callback function.

Re: "and also the PHP you're using to read the setting when a refresh happens". I don't use anything like that.
I was about to look into that, but then I noticed that after switching from option to theme_mod it wasn't necessary anymore. Changes in settings with transport = 'postMessage' were also saved before a refresh happened. I was happy with that, but still thought I should report the difference that I noticed.

However, today I created a very basic test case and there the difference between type option and theme_mod was gone. In both cases changes in settings with postMessage were lost if you didn't save before changing things like "Static Front Page" or "Navigation" that use refresh.

I am still debugging to find out what causes the different behaviour in the theme I was working on and my basic test case. When I am done I will comment again and attach the files.

6 years ago

Test theme functions

6 years ago

Test theme script

6 years ago

Test theme index

6 years ago

Test theme style

#3 @jaspermdegroot
6 years ago

First I thought it had to do with theme_mods vs. theme options, but I don't think it has to do with that anymore so the title of this ticket is a bit misleading

I uploaded the four files of my test theme that I created to debug the issue. The theme uses theme_mods. I added four settings that all use transport postMessage and I made the site title and description settings use transport postMessage as well.

To reproduce:

Make sure you have a custom nav menu for testing purposes.
Go to the customizer and change the site title and description, change the header and site background color, upload a logo, and change the setting for content text alignment.
The live preview JS is working as expected so you directly see the changes.
Now change the setting for "Main menu" in Navigation to trigger a refresh.

Result: The site title and description still show the new value and the content text alignment is also still according the new value. However, the uploaded logo is gone and the header and site background lost their new color and now have the last saved colors again.

Although you don't see the logo and the new colors anymore, when you click "Save & Publish" they are saved. So this about the live preview only.

I am not sure how it should behave by design, but I would expect that all settings with transport postMessage show the same behaviour.

Tested with WordPress latest of 12/16/2014 on OS X / Chome 39 and Firefox 34.

#4 @westonruter
4 years ago

@jaspermdegroot wow, 20 months files by fast. Is this still an issue?

#5 @jaspermdegroot
4 years ago


Not so long ago I was running into this problem again, so I think it's still an issue but have to test with latest code to be sure.

#6 @jaspermdegroot
4 years ago

  • Keywords reporter-feedback removed

#7 @westonruter
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

@jaspermdegroot Thanks for the helpful code and steps to reproduce. I've found the problem. It's actually a known issue (#24844) where get_theme_mods() isn't returning the customizer-previewed values. The fix is simply to use get_theme_mod() instead. I've implemented this and fixed an issue with the content alignment sanitize callback here: https://gist.github.com/westonruter/c9b9cf597e9e9129070d67b68920168e/revisions

Note: See TracTickets for help on using tickets.