4.4 Customizer - serialized options can no longer be created

[Looimaster]

When I do this:

<?php
function test_customize_register() {
$wp_customize->add_setting( 'my_theme_name_options[my_option_name]', array(
        'default' => '',
        'type' => 'option',
        'transport' => 'postMessage',
) );

$wp_customize->add_control( new WP_Customize_Control( $wp_customize, 'my_theme_name_options[my_option_name]', array(
        'label' => __( 'My label', 'theme-name' ),
        'section' => 'my_section_name',
        'type' => 'textarea',
) ) );
}
add_action( 'customize_register', 'test_customize_register' );

it doesn't CREATE my_theme_name_options[my_option_name] in wp_options database table (not correct).

However, if my_option_name already exists in my_theme_name_options in wp_options database table then it is UPDATED (correct).

When I do it as theme_mod it works:

<?php
$wp_customize->add_setting( 'my_option_name', array(
        'default' => '',
        'type' => 'theme_mod',
        'transport' => 'postMessage',
) );

$wp_customize->add_control( new WP_Customize_Control( $wp_customize, 'my_option_name', array(
        'label' => __( 'My label', 'theme-name' ),
        'section' => 'my_section_name',
        'type' => 'textarea',
) ) );

What I tried:

• Made sure there are no PHP/JS errors, the file is almost as simple as this.
• Enabled WP_DEBUG and logs and there were no PHP errors.
• Clicking "Save & Publish" indicates as if saving was successful but upon page refresh option is not created.
• PHPMyAdmin doesn't show that database option is updated.
• When I update this database option by other means (e.g. from admin page) it works.
• Re-installed WordPress 4.4 in Dashboard > Updates.
• Switched textarea to default field.
• Created more fields and shortened my_theme_name_options[my_option_name] to my_opts[opt_name] but it didn't help.
• Finally, created non-serialized option called my_option_name and it works (such option is CREATED and can be UPDATED).

Conclusion: Serialized database entries are not created. They can be updated though if they were created outside Customizer.

[westonruter]

@Looimaster From your first example with options, I can see that $wp_customize would is undefined since it isn't being passed in to the function, and it isn't being declared as global. Is that just a typo in the description?

[westonruter]

@Looimaster I cannot reproduce. Here is a video: ​https://cloudup.com/cvhDAmPBkpQ

I put this code into a mu-plugin to test:

<?php

function test_customize_register( \WP_Customize_Manager $wp_customize ) {
        $wp_customize->add_section( 'my_section_name', array(
                'title' => 'Trac 35168',
        ) );

        $wp_customize->add_setting( 'my_theme_name_options[my_option_name]', array(
                'default' => '',
                'type' => 'option',
                'transport' => 'postMessage',
        ) );

        $wp_customize->add_control( new WP_Customize_Control( $wp_customize, 'my_theme_name_options[my_option_name]', array(
                'label' => __( 'My label', 'theme-name' ),
                'section' => 'my_section_name',
                'type' => 'textarea',
        ) ) );
}
add_action( 'customize_register', 'test_customize_register' );

[Looimaster]

It's a typo. I added the following three lines as an afterthought (so that you know that I'm using the correct action hook):

function test_customize_register() {
}
add_action( 'customize_register', 'test_customize_register' );

I tested it with function test_customize_register( $wp_customize ) {.

I tested it in Twenty Sixteen in /inc/customizer.php and it works.

I tested it with a theme that copies and modifies Twenty Sixteen and it clearly still doesn't work. And it's just with serialized options. I'll close this ticket and reopen when/if I find the cause.

[Looimaster]

For anyone having the same issue this was my problem:

function tn_options_init() {
	register_setting( 'tn_options', 'my_theme_name_options', 'tn_validate' );
	add_settings_section( 'general', '', '__return_false', 'theme_options' );
	add_settings_field( 'x', __( 'x', 'tn' ), 'tn_settings_field_x', 'theme_options', 'general' );
	add_settings_field( 'y', __( 'y', 'tn' ), 'tn_settings_field_y', 'theme_options', 'general' );
	add_settings_field( 'z', __( 'z', 'tn' ), 'tn_settings_field_z', 'theme_options', 'general' );
}
add_action( 'admin_init', 'tn_options_init' );

It looks like if you use my_theme_name_options in register_setting() then you can't be using it in Customizer. Or tn_validate must include sanitization for all your admin page options and Customizer options.

I thought Customizer does saving separately and has its own sanitization callback and I didn't suspect that something else may be interfering.

When I mentioned that I renamed that to my_opts[opt_name] and it didn't work then it's because I actually renamed that database setting everywhere using "Find and replace in Files..." and not just in my /inc/customizer.php.

It's not a bug then.