Customizer assigns invalid values to header_image_data theme mod during preview

[bradyvercher]

Some background: The custom header feature uses two theme mods to store data: header_image and header_image_data. These are kept in sync by routing everything through Custom_Header_Image::set_header_image(), which transforms the data as needed before saving.

Looking at that method, these are the values that can exist for each:

• header_image: Can have the URL to an image, remove-header, random-default-image, or random-uploaded-image.
• header_image_data: Always contains an object with header properties. At a minimum, it should have a url and thumbnail_url property, but may contain additional data.

This is difficult to demonstrate in a default theme right now since most use get_header_image() and manually construct an image tag, which uses the header_image mod. However the_header_image_tag() and the_custom_header_markup() end up relying on get_custom_header(), which uses the header_image_data theme mod. So when an unrecognized value is passed from the Customizer, default headers end up not displaying at all in the preview.

To reproduce:

1. Switch to Twenty Ten
2. Open twentyten/header.php and replace the header image markup with the_header_image_tag()
3. Access the Customizer and open the "Header Image" section
4. Choose one of the "Suggested" headers

Notice that the header image doesn't display in the preview.

Type wp.customize( 'header_image_data' )() in the JS console and notice that the value is a string identifier for the image. When changes are saved in the Customizer, that value does get converted to the expected object so everything works when viewing the front end, but the preview will be broken.

This will eventually become more noticeable as themes begin using the_header_image_tag() for responsive header images or the_custom_header_markup() for video headers.

[bradyvercher]

All the data needed for previewing appears to be available in the Customizer, so instead of passing unexpected values into theme mods, 38558.diff​ mimics the format used in Custom_Header_Image::set_header_image() when saving the theme mods.

[bradyvercher]

Actually, it looks like that change on its own prevented the header_image_data theme mod from from saving. 38558.1.diff​ fixes the save routine.

[westonruter]

Milestoning for future release, but if @joemcgill wants to prioritize for 4.7 he can re-milestone.

[bradyvercher]

I think the most visible effect of this issue got fixed in #38633, so it's not really noticeable anymore unless any other code is relying on the header_image_data theme mod in the Customizer.

[celloexpressions]

Closing this for now since (based on elapsed time) it looks like there is in fact little-to-no code relying on this theme mod beyond what was fixed in #38633. Please reopen if anyone finds other situations where this issue surfaces.