WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#27848 closed defect (bug) (fixed)

WP_Customize_Image_Control and Custom Header Issue

Reported by: thelukemcdonald Owned by: nacin
Milestone: 3.9.1 Priority: normal
Severity: normal Version: 3.9
Component: Customize Keywords: has-patch commit
Focuses: javascript Cc:

Description

It appears the "Remove Image" link in the WP_Customize_Image_Control does not show when a theme supports Custom Headers in 3.9. Everything seems to work as expected in 3.8.3.

Below are steps to replicate the issue. I put together a quick theme using _s and attached it to this ticket. The theme includes support for Custom Headers and has a WP_Customize_Image_Control setting in the customizer.

  1. Download _s theme.
  2. Network active theme.
  3. Active _s theme for site.
  4. Uncomment require get_template_directory() . '/inc/custom-header.php' in functions.php
  5. Add a WP_Customize_Image_Control control to the customizer settings.
  6. Go to Appearance > Customize > Site Title & Tagline
  7. Upload image via the "Logo" setting
  8. NOTE: The image uploads and the "Remove Image" links shows as expected. However...
  9. Close Customizer screen.
  10. Open customizer again and try to remove "Logo" image. "Remove Image" link is gone.
  11. Comment out require get_template_directory() . '/inc/custom-header.php' in functions.php
  12. Open customizer and try to remove "Logo" image. "Remove Image" link appears.

Attachments (4)

customizer-test.zip (49.6 KB) - added by thelukemcdonald 6 years ago.
Modified _s theme
custom-header-not-supported.jpg (30.8 KB) - added by thelukemcdonald 6 years ago.
Customizer screenshot
27848.patch (450 bytes) - added by rzen 6 years ago.
27848.2.diff (442 bytes) - added by ehg 6 years ago.

Download all attachments as: .zip

Change History (26)

@thelukemcdonald
6 years ago

Modified _s theme

@thelukemcdonald
6 years ago

Customizer screenshot

#1 @thelukemcdonald
6 years ago

I should also mention there were not any plugins activated.

#2 follow-up: @rzen
6 years ago

  • Component changed from General to Themes

So this is a very curious bug. I couldn't replicate it on a site that was simply running 3.9, I had to start over with a fresh install. Same setup as described, no plugins, using the attached _s base theme.

I found that the link is still present, but via JS it was set to display:none: http://d.pr/i/yOcu+

I say this is set via JS, because the link itself is generated without any inline CSS: https://core.trac.wordpress.org/browser/tags/3.9/src/wp-includes/class-wp-customize-control.php#L575

I haven't found any strong leads as to where this is coming from, though.

#3 @rzen
6 years ago

  • Focuses ui added

#4 @thelukemcdonald
6 years ago

That is strange. I show the link as having the display: none inline style in the inspector, too, however, the link is not visible in my case. As of right now, the only way to remove a previously set image is to upload a new image. Doing that, the "Remove Image" link becomes visible again, this time having an inline style of display: inline. However, if I close the customizer and go back to that setting, the "Remove Image" does not show.

I was going to look into this but figured the customizer control was handled with a bunch JS/Backbone stuff which is way above my head in most cases :)

#5 @rzen
6 years ago

You're right about it all being handled via Backbone :)

Here's what's happening:

During api.HeaderControl.ready(), on lines 322-325 of customize-controls.js, we instantiate a new api.HeaderTool.CurrentView.

Inside of api.HeaderTool.CurrentView is a method called setButtons(), seen on line 72 of customize-views.js. This gets called during render, which is called when the moment the view is instantiated in api.HeaderControl.ready().

The sole purpose api.HeaderTool.CurrentView.setButtons() is to determine whether or not .actions .remove should be shown or hidden based on the current view.

The issue here is that setButtons() is targeting any matching elements via$('.actions .remove') and instead the selector should be limited to the view's scope (e.g. this.$el.find('.actions .remove')). I know that fixes the problem, anyway, but I'm not sure what other problems it may create.

I'm going to dig in a bit more.

Version 0, edited 6 years ago by rzen (next)

@rzen
6 years ago

#6 @rzen
6 years ago

  • Focuses javascript added
  • Keywords has-patch dev-feedback needs-testing added

The patch I've just submitted applies the fix I described above. I don't have enough familiarity with this to properly test for anything that it might be breaking.

I think egh, gcorne, and nacin are probably the best to evaluate this based on their involvement with #21785

#7 @rzen
6 years ago

  • Focuses ui removed

#8 @obenland
6 years ago

  • Component changed from Themes to Appearance
  • Milestone changed from Awaiting Review to 3.9.1

#9 @seanchayes
6 years ago

I followed the steps thelukemcdonald outlined, in my case I crafted my own _s theme.

After adding in the custom WP_Customize_Image_Control and then applying a logo, closing and reopening the customizer screen, I experienced the missing "Remove image" button.

I continued as thelukemcdonald described and saw that the button re-appeared when the "require ...'/inc/custom-header.php'" line was commented out.

I then applied the patch from rzen and found the button appears as expected regardless of whether the custom-header.php line is commented out or not.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


6 years ago

This ticket was mentioned in IRC in #wordpress-dev by davidakennedy. View the logs.


6 years ago

@ehg
6 years ago

#12 @ehg
6 years ago

attachment:27848.2.diff fixes this problem, without impacting the Header control's functionality. Unfortunately this.$el.find('.actions .remove') won't work, as the button isn't in the CurrentView's scope (it probably should be).

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


6 years ago

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.


6 years ago

#15 @nacin
6 years ago

  • Owner set to nacin
  • Status changed from new to assigned

#16 in reply to: ↑ 2 @ZaneMatthew
6 years ago

Replying to rzen:

So this is a very curious bug. I couldn't replicate it on a site that was simply running 3.9, I had to start over with a fresh install. Same setup as described, no plugins, using the attached _s base theme.

I found that the link is still present, but via JS it was set to display:none: http://d.pr/i/yOcu+

I say this is set via JS, because the link itself is generated without any inline CSS: https://core.trac.wordpress.org/browser/tags/3.9/src/wp-includes/class-wp-customize-control.php#L575

I haven't found any strong leads as to where this is coming from, though.

I'm experiencing the same issue and found the same results.

#17 @ocean90
6 years ago

Related: #28046

#18 @nacin
6 years ago

  • Keywords commit added; dev-feedback needs-testing removed

#19 @nacin
6 years ago

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

In 28266:

Customizer: Avoid hiding 'Remove' buttons unrelated to custom headers.

props rzen, ehg.
fixes #27848.

#20 @nacin
6 years ago

In 28267:

Customizer: Avoid hiding 'Remove' buttons unrelated to custom headers.

Merges [28266] to the 3.9 branch.

props rzen, ehg.
fixes #27848.

#21 @nacin
6 years ago

In 28269:

Customizer: Only tie header button action events to the header controls.

props danielbachhuber.
fixes #28046. see #27848.

#22 @nacin
6 years ago

In 28270:

Customizer: Only tie header button action events to the header controls.

Merges [28269] to the 3.9 branch.

props danielbachhuber.
fixes #28046. see #27848.

Note: See TracTickets for help on using tickets.