WordPress.org

Make WordPress Core

Opened 5 months ago

Closed 5 weeks 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)

clipped-header.png (397.9 KB) - added by bradyvercher 5 months ago.
38559.dff (1.6 KB) - added by bradyvercher 5 months ago.
38559.diff (1.6 KB) - added by westonruter 6 weeks ago.
Fix attachment file extension
with-patch-applied.png (680.9 KB) - added by westonruter 5 weeks ago.

Download all attachments as: .zip

Change History (18)

@bradyvercher
5 months ago

#1 @bradyvercher
5 months ago

  • Keywords has-patch added

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 of 40 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.

#2 follow-up: @westonruter
5 months 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 @bradyvercher
5 months 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.

#4 @joemcgill
3 months ago

#39322 was marked as a duplicate.

#5 in reply to: ↑ 2 @celloexpressions
3 months ago

Replying to westonruter:

@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.

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.


6 weeks ago

#7 @westonruter
6 weeks ago

#27757 was marked as a duplicate.

#8 @westonruter
6 weeks ago

  • Milestone changed from Future Release to 4.7.3
  • Owner set to westonruter
  • Status changed from new to accepted

#9 @westonruter
6 weeks ago

  • Keywords needs-testing added

@westonruter
6 weeks ago

Fix attachment file extension

#10 @dlh
6 weeks 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 @westonruter
5 weeks 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

#12 @westonruter
5 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 40082:

Customize: Prevent vertical clipping of thumbnail in header image customizer control.

Removes some method overrides on wp.customize.HeaderTool.ChoiceView introduced in [27497].

See #21785.
Props bradyvercher.
Fixes #38559.

#13 @westonruter
5 weeks ago

  • Keywords has-screenshots fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening for consideration in 4.7.3

#14 @dd32
5 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 40100:

Customize: Prevent vertical clipping of thumbnail in header image customizer control.

Removes some method overrides on wp.customize.HeaderTool.ChoiceView introduced in [27497].

See #21785.
Props bradyvercher, westonruter.
Merges [40082] to the 4.7 branch.
Fixes #38559.

Note: See TracTickets for help on using tickets.