[wp-trac] [WordPress Trac] #21918: WP_Customize_Control() doesn't work with add_setting() default theme_mod type
WordPress Trac
wp-trac at lists.automattic.com
Tue Sep 18 11:29:03 UTC 2012
#21918: WP_Customize_Control() doesn't work with add_setting() default theme_mod
type
---------------------------------------+--------------------------
Reporter: sebstyle | Type: defect (bug)
Status: new | Priority: normal
Milestone: Awaiting Review | Component: Themes
Version: 3.4.2 | Severity: normal
Keywords: needs-testing needs-patch |
---------------------------------------+--------------------------
Consider the following code:
{{{
$wp_customize->add_setting($color,array(
'default' => '#000000',
'sanitize_callback' => 'sanitize_hex_color',
'capability' => 'edit_theme_options',
'transport' => 'postMessage'
)
);
$wp_customize->add_control(new
WP_Customize_Color_Control($wp_customize,$color,array(
'label' => 'somelabel',
'section' => 'colors'
)
)
);
}}}
The default 'type' used for add_setting() is 'theme_mod' as defined in
http://codex.wordpress.org/Class_Reference%5CWP_Customize_Manager%5Cadd_setting
The WP_Customize_Color_Control '''does not''' accept the 'default' setting
when there is no 'type' specified.
The WP_Customize_Color_Control '''does accept''' the 'default' setting
when 'type' is either set to 'option' or 'theme_mods'.
Setting it to 'option' makes no sense because that would imply that one
would be using a custom option database field with get_option() instead of
the default database field used by get_theme_mod().
Because setting it to 'theme_mods' works and 'theme_mod' does not i
suggest checking code for typos.
Expected behavior would be for it to work with theme_mod/get_theme_mod
stored values when the default 'type' is used.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/21918>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list