Opened 12 years ago
Closed 9 years ago
#21918 closed defect (bug) (invalid)
WP_Customize_Control() doesn't work with add_setting() default theme_mod type
Reported by: | sebstyle | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.4.2 |
Component: | Customize | Keywords: | reporter-feedback close |
Focuses: | Cc: |
Description
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.
Change History (7)
#2
@
12 years ago
- Keywords reporter-feedback added; needs-testing needs-patch removed
- Milestone changed from 3.5 to Awaiting Review
#3
follow-up:
↓ 4
@
12 years ago
Note that once you set a color through the UI, there is no way to clear it, so that you get the default value again.
To test the default, you either need to remove the color via some code or change the $color variable.
I pasted that exact code and it works as expected (get black as the default color) in WP 3.5-alpha.