get_theme_mod called when getting the root value of a custom type

[jontis]

Notice the else if statement

/* wp-includes/class-wp-customize-setting.php:533 */
protected function get_root_value( $default = null ) {
                $id_base = $this->id_data['base'];
                if ( 'option' === $this->type ) {
                        return get_option( $id_base, $default );
                } else if ( 'theme_mod' ) {
                        return get_theme_mod( $id_base, $default );
                } else {
                        /*
                         * Any WP_Customize_Setting subclass implementing aggregate multidimensional
                         * will need to override this method to obtain the data from the appropriate
                         * location.
                         */
                        return $default;
                }
        }

Same bug applies to set_root_value

This can cause the Customizer to fail loading with the error
"sprintf(): Too few arguments"
On the sprintf function in get_theme_mod if $default is a string containing more than two % (percentage symbols)

[ocean90]

Hello @jontis, welcome to this Trac!

Thanks for your valid report. We're already tracking this issue in #34290.

[jontis]

Replying to ocean90:

Hello @jontis, welcome to this Trac!

Thanks for your valid report. We're already tracking this issue in #34290.

Issue #34290 does not mention the odd else if statement in get_root_value

<?php
else if ( 'theme_mod' )

[dlh]

I might be misreading something, but it looks to me like @jontis is correct that this issue is not quite a duplicate of #34290. 36952.diff​ would update the two instances of if ( 'theme_mod' ) without comparisons to anything.

[westonruter]

Wow, youch! That is a sad bug in \WP_Customize_Setting::get_root_value()! Introduced by me (😳) in r35007 for #32103.

[westonruter]

@dlh would you be able to add unit tests to your patch to demonstrate the problem and the proven fix?

[dlh]

Yes, I should be able to in the next few days.

[dlh]

36952.2.diff​ amends the WP_Customize_Setting tests so that they trigger the bug in get_root_value().

Currently, core calls set_root_value() only in WP_Customize_Setting::update(), and even then, only after checking whether 'option' === $this->type || 'theme_mod' === $this->type. So, I think only a setting class with custom logic could trigger the set_root_value() bug. Let me know if you'd like me to add one to the tests.

[westonruter]

In 40036:

Customize: Ensure root values are accessible in multidimensional custom setting types.

Fixes bad conditions in WP_Customize_Setting::get_root_value() and WP_Customize_Setting::set_root_value().

Props dlh.
Amends [35007].
See #32103.
Fixes #36952.

[westonruter]

Re-opening for 4.7.3

[dd32]

In 40088:

Customize: Ensure root values are accessible in multidimensional custom setting types.

Fixes bad conditions in WP_Customize_Setting::get_root_value() and WP_Customize_Setting::set_root_value().

Props dlh, westonruter.
Amends [35007].
Merges [40036] to the 4.7 branch.
See #32103.
Fixes #36952.