Opened 13 years ago
Closed 13 years ago
#20600 closed defect (bug) (fixed)
Customize and display_header_text()
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.4 | Priority: | normal |
Severity: | normal | Version: | 3.4 |
Component: | Customize | Keywords: | |
Focuses: | Cc: |
Description
The header color and display checkbox in the customizer do not work with the new display_header_text() function (see #18887) because display_header_text() thinks an empty string is a hidden header, while Customize assumes than an empty string is the default color, while "blank" is a hidden header.
How to reproduce (using a theme that supports header images, but not the new twenty ten/eleven because they now use postMessage):
- Go to Appearance > Header
- Remove any header image and hit Restore Original Header Text if available
- Uncheck Show header text with your image
- Go to Customize and check Display header text
You'll see that the color value says "Default", the actual color string passed will be an empty string, so display_header_text() will think it's hidden. I wrote this dirty snippet that outputs some debug info that might help:
add_action( 'wp_head', function() { $header_text = display_header_text(); $header_textcolor = get_header_textcolor(); echo 'header_text: '; var_dump( $header_text ); echo '<br />'; echo 'header_text_color != blank: '; var_dump( $header_textcolor != 'blank' ); echo '<br />'; echo 'header_text_color: '; var_dump( $header_textcolor ); echo '<br />'; });
Try the reproduce steps again to see how the two methods (display_header_text and comparison to blank) differ at some point.
Attachments (1)
Change History (12)
#1
@
13 years ago
- Component changed from General to Appearance
- Milestone changed from Awaiting Review to 3.4
#5
@
13 years ago
I think 20600.diff is still needed to avoid Customize from stomping on the 'blank' value.
#7
@
13 years ago
- Keywords commit added
I think without [20600.diff], the customizer is stomping hidden headers. koopersmith, how's the patch?
#9
@
13 years ago
- Keywords has-patch commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
We also need to pass the default color to JS to fix this bug — currently the "Default" color in the preview will be whatever color the preview loaded with, which could already be set to a theme_mod value (and not the real default).
Uses a sanitize function to convert an empty string to the default header color for the theme, also accepts "blank" and properly sanitizes the rest.