[wp-trac] [WordPress Trac] #51592: Customizer: Create New Menu is Empty

[WordPress Trac]

#51592: Customizer: Create New Menu is Empty
--------------------------+---------------------
 Reporter:  boldgrid      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.6
Component:  Customize     |     Version:  trunk
 Severity:  blocker       |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:11 david.binda]:
 Ha, was just about to attach pretty much the same patch, but you beat me
 to it! :)

 > The biggest part of the diff in between the 2.2.4 and 3.0.0 is the
 Deferred element you are mentioning.
 >
 > However, even in 2.2.4, the parentNode seems to be set (just `.parent()`
 is not returning it).

 My "current guess" is that this is timing related. Looking at 5.5, when
 the `deferred` in `inject` runs, none of the
 `control.container[0].parentNode` exist yet, or are in a
 `DocumentFragment` (not in the DOM yet, so jQuery cannot find the parent).
 So `control.container.parent().is( parentContainer )` is always `false`.
 Logs:

 {{{
 sectionId ===  nav_menu[5]
 control.container[0].parentNode null
 control.container.parent()[0] Object { length: 0, prevObject: {…},
 context: undefined }
 control.container.parent().is( parentContainer ) false
 ----------------------------------------
 sectionId ===  add_menu
 control.container[0].parentNode null
 control.container.parent()[0] Object { length: 0, prevObject: {…},
 context: undefined }
 control.container.parent().is( parentContainer ) false
 ----------------------------------------
 sectionId ===  add_menu
 control.container[0].parentNode null
 control.container.parent()[0] Object { length: 0, prevObject: {…},
 context: undefined }
 control.container.parent().is( parentContainer ) false
 ----------------------------------------
 sectionId ===  menu_locations
 control.container[0].parentNode DocumentFragment [ li#customize-control-
 nav_menu_locations-top.customize-control.customize-control-
 nav_menu_location ]
 control.container.parent()[0] Object { length: 0, prevObject: {…},
 context: undefined }
 control.container.parent().is( parentContainer ) false
 ----------------------------------------
 }}}

 However in 5.6-beta the same debug logging outputs:
 {{{
 sectionId ===  menu_locations
 control.container[0].parentNode DocumentFragment [ li#customize-control-
 nav_menu_locations-social.customize-control.customize-control-
 nav_menu_location ]
 control.container.parent()[0] Object { length: 0, prevObject: {…} }
 control.container.parent().is( parentContainer ) false
 ----------------------------------------
 sectionId ===  nav_menu[10]
 control.container[0].parentNode <ul id="sub-accordion-section-
 nav_menu[10]" class="customize-pane-child acc...">
 control.container.parent()[0] Object { 0: ul#sub-accordion-section-
 nav_menu[10].customize-pane-child.acc..., length: 1, prevObject: {…} }
 control.container.parent().is( parentContainer ) true
 ----------------------------------------
 sectionId ===  add_menu
 control.container[0].parentNode <ul id="sub-accordion-section-add_menu"
 class="customize-pane-child acc...">
 control.container.parent()[0] Object { 0: ul#sub-accordion-section-
 add_menu.customize-pane-child.acc..., length: 1, prevObject: {…} }
 control.container.parent().is( parentContainer ) true
 ----------------------------------------
 }}}

 The `nav_menu` and `add_menu` containers are already in the DOM, the other
 containers are not and `control.container.parent().is( parentContainer )`
 is still `false` for them.

 > I wonder, can't the `control.renderContent();` call be moved outside of
 the conditional leaving only the `.append` inside?

 Yes, testing this here seems to work. Pinging @westonruter for a review.

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