Opened 9 years ago
Closed 8 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: |
Description
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)
Change History (11)
#2
@
9 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.
#3
@
9 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.
#5
@
8 years ago
@westonruter
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.
#7
@
8 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
Thanks for the report, jaspermdegroot.
Are you observing this same behavior in 3.9? Also, I assume your
$wp_customize
calls are inside of somecustomize_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?