Make WordPress Core

Opened 8 years ago

Closed 3 years ago

#38558 closed defect (bug) (maybelater)

Customizer assigns invalid values to header_image_data theme mod during preview

Reported by: bradyvercher's profile bradyvercher Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9
Component: Customize Keywords: has-patch
Focuses: Cc:


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.

Attachments (2)

38558.diff (1.2 KB) - added by bradyvercher 8 years ago.
38558.1.diff (2.1 KB) - added by bradyvercher 8 years ago.

Download all attachments as: .zip

Change History (7)

8 years ago

#1 @bradyvercher
8 years ago

  • Keywords has-patch added

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.

8 years ago

#2 @bradyvercher
8 years ago

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

Version 0, edited 8 years ago by bradyvercher (next)

#3 @westonruter
8 years ago

  • Milestone changed from Awaiting Review to Future Release

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

#4 @bradyvercher
8 years ago

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.

#5 @celloexpressions
3 years ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.