Opened 8 years ago
Closed 8 years ago
#38559 closed defect (bug) (fixed)
Current header image gets clipped in the Customizer
Reported by: | bradyvercher | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.7.3 | Priority: | normal |
Severity: | normal | Version: | 3.9 |
Component: | Customize | Keywords: | has-patch commit has-screenshots fixed-major |
Focuses: | Cc: |
Description
I've noticed this a few times in the past, but the thumbnail for the Current Header image in the Customizer will get clipped on occasion, especially when cycling between various "Suggested" headers.
Attachments (4)
Change History (18)
#2
follow-up:
↓ 5
@
8 years ago
- Milestone changed from Awaiting Review to Future Release
@bradyvercher Should not the header image control be taken further to extend the MediaControl
instead of Control
? It seems that there is some logic in here that is redundant. All that should be needed is the header image attachment ID and the attachment data (and image size URLs) should be fetched when the control is embedded, like in #36521.
I don't see why we need both the header_image
and the header_image_data
setting.
#3
@
8 years ago
@westonruter Header images don't always have attachment IDs since there can be one or more registered defaults that come directly from the theme, so just about everything is based on URLs right now. The MediaControl
uses attachment IDs, so most of the methods would have to be overridden anyway.
The header_image_data
setting isn't used much in core and appears to mainly be used to keep track of an attachment ID when one is available since header_image
stores a URL (and a couple of other strings). The header functionality could be simplified, but there's a lot of backward compatibility baggage that would need to be considered.
#5
in reply to:
↑ 2
@
8 years ago
Replying to westonruter:
@bradyvercher Should not the header image control be taken further to extend the
MediaControl
instead ofControl
? It seems that there is some logic in here that is redundant. All that should be needed is the header image attachment ID and the attachment data (and image size URLs) should be fetched when the control is embedded, like in #36521.
I don't see why we need both the
header_image
and theheader_image_data
setting.
The header image control needs to be totally refactored to make use of the media control hierarchy, JS-templated controls, and even the customizer JS API, since it was introduced before any of those existed. See #36581.
Realistically, I think it would be best to prioritize that larger refactoring over all of these individual bugs for the header image control, as many would be fixed in the process. All of the media controls will benefit, with things like #32861 being fixed in the process. If anyone is interested in taking on that project I'd be happy to assist with any questions on the implementation.
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
8 years ago
#8
@
8 years ago
- Milestone changed from Future Release to 4.7.3
- Owner set to westonruter
- Status changed from new to accepted
#10
@
8 years ago
I can replicate the bug through only one set of steps: Open the Customizer in Twenty Seventeen, preview another theme, then preview Twenty Seventeen again and go to the Header Media section. But 38559.diff fixes the bug when following those steps.
#11
@
8 years ago
- Keywords commit added; needs-testing removed
I can also reproduce by merely looking at the header image control in Twenty Seventeen /wp-admin/customize.php?theme=twentyseventeen&autofocus[section]=header_image
It turns out the Customizer attempts to use size data stored in
header_image_data
, but the registered default images don't have any sizing or attachment data, so the size is guessed before falling back to a default of40
for the height. If an image exists in the browser cache, it tends to load fast enough that JS can determine its size, but if the image load event hasn't fired yet, the size is unknown. That's typically when the thumbnail gets clipped like clipped-header.png.That being said, it looks like the code for setting the height is completely unnecessary and CSS could be used if a maximum height is desired. 38559.dff removes the code for setting the height on that container.