[wp-trac] [WordPress Trac] #27848: WP_Customize_Image_Control and Custom Header Issue

[WordPress Trac]

#27848: WP_Customize_Image_Control and Custom Header Issue
-----------------------------+------------------------------
 Reporter:  thelukemcdonald  |       Owner:
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Themes           |     Version:  3.9
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  ui
-----------------------------+------------------------------

Comment (by rzen):

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

 Here's what's happening:

 During `api.HeaderControl.ready()`, on
 [https://core.trac.wordpress.org/browser/tags/3.9/src/wp-admin/js
 /customize-controls.js#L322 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 [https://core.trac.wordpress.org/browser/tags/3.9/src/wp-admin/js
 /customize-views.js#L72 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27848#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform