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.

[agilexcmer]

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.

[lancewillett]

Ignore. :) Wrong ticket.

[lancewillett]

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

[obenland]

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

[obenland]

Adds comment

[aaroncampbell]

Since this isn't new and I don't think the offered solutions are really what we want, I'm punting this one out of 3.6

[aaroncampbell]

Sorry, too many Trac windows open I guess. That was meant for a different ticket.

[aaroncampbell]

23761.1.diff​ works to avoid this issue. If you've already had the issue you'll need to save in the Customizer or Appearance->Header to fix it, but I doubt anyone really left it broke, so I think we're ok here.

Replying to lancewillett:

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

They don't seem to be related (background color and header text color), the patch from there has no effect here, and the solution seems to be different anyway because we have a theme specify a default header text color via add_theme_support( 'custom-header', $args ); whereas the default background color is supposed to be specified in the CSS.

[nacin]

This seems related to #22030, tangentially — in that case, we're saving the default when we should really be deleting/emptying the theme mod.

In this case, we're now *trying* to deliberately save the default. While it may work, is this the right fix?

[nacin]

I think Aaron is right here. I don't love it, but it's how custom-header.php works too.

[nacin]

In 24687:

Avoid empty header color after enabling header text via Customizer. props obenland, fixes #23761.