WP_Customize_Image_Control and Custom Header Issue

[thelukemcdonald]

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.

[thelukemcdonald]

Modified _s theme

[thelukemcdonald]

Customizer screenshot

[thelukemcdonald]

I should also mention there were not any plugins activated.

[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:

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.

[thelukemcdonald]

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 :)

[rzen]

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') on line 73 of customize-views.js. Instead, the selector should be limited to the view's scope (e.g. this.$el.find('.actions .remove')). I know that fixes this problem, anyway, but I'm not sure what other problems it may create. :)

I'm going to dig in a bit more.

[rzen]

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

[seanchayes]

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.

[ehg]

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

[ZaneMatthew]

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:

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.

[ocean90]

Related: #28046

[nacin]

In 28266:

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

props rzen, ehg.
fixes #27848.

[nacin]

In 28267:

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

Merges [28266] to the 3.9 branch.

props rzen, ehg.
fixes #27848.

[nacin]

In 28269:

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

props danielbachhuber.
fixes #28046. see #27848.

[nacin]

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.