Empty header color after enabling header text via Customizer

[SergeyBiryukov]

Background: #23722

1. Go to Appearance > Header, disable header text.
2. Go to Customizer, enable header text.
3. Go to Appearance > Header again. get_header_textcolor() will return an empty value.

Bundled themes handle this situation differently:

• Twenty Thirteen shows the header with a wrong color (see the screenshot).
• Twenty Twelve also has an empty color in the style attribute (as in the screenshot), but it still shows the correct color due to the declaration in twentytwelve_admin_header_style(): http://core.trac.wordpress.org/browser/tags/3.5.1/wp-content/themes/twentytwelve/inc/custom-header.php#L109
• Twenty Eleven doesn't display the header on Appearance > Header screen at all after those steps, because it specifically checks that get_header_textcolor() is not empty: http://core.trac.wordpress.org/browser/tags/3.5.1/wp-content/themes/twentyeleven/functions.php#L313

If you disable and re-enable header text on Appearance > Header screen, the correct color will be restored.

This is for TwentyThirteen. In Line 217 of wp-admin/custom-header.php:

if ( isset( $_POST['text-color'] ) && ! isset( $_POST['display-header-text'] ) ) {
			check_admin_referer( 'custom-header-options', '_wpnonce-custom-header-options' );
			set_theme_mod( 'header_textcolor', 'blank' );
		} elseif ( isset( $_POST['text-color'] ) ) {
			check_admin_referer( 'custom-header-options', '_wpnonce-custom-header-options' );
			$_POST['text-color'] = str_replace( '#', '', $_POST['text-color'] );
			$color = preg_replace('/[^0-9a-fA-F]/', '', $_POST['text-color']);
			if ( strlen($color) == 6 || strlen($color) == 3 )
				set_theme_mod('header_textcolor', $color);
			elseif ( ! $color )
				set_theme_mod( 'header_textcolor', 'blank' );
		}

If the header text is disabled, WP sets the colour option to the string "blank" (and also for cases where the colour is invalid). This is how it knows whether you have the header text set or not.

When the customizer loads, the backend will provide it with an invalid color (string "blank") to begin with. I think this is filtered somewhere to then become an empty string.

Enabling the header in the customizer shows the header color option, which deceptively shows a colour. The actual colour is invalid (just a "#"), but then the browser applies the default colour for anchor tags. When you save the header in the customizer, it saves it with an empty string colour (you can check this in the database, serialized value theme_mods_twentythirteen in wp_options).

In the Appearance->Header, the colour is again invalid, but the header anchor tag has a default colour blue, which is what you see. The default colour for the colour-picker's anchor is different, which is why it shows something whitish.

I think the problem comes from the fact that we're re-using the header colour to determine if the header is enabled or not.

Ignore. :) Wrong ticket.

Can you test with patch on #22030 ? Could be related.

Patch adds a check for an empty color string and uses the default text color in that case.

Adds comment