[wp-trac] [WordPress Trac] #39665: Customize: nav menu fallbacks don't get edit shortcuts

WordPress Trac noreply at wordpress.org
Fri May 19 03:24:04 UTC 2017


#39665: Customize: nav menu fallbacks don't get edit shortcuts
-------------------------------------+------------------
 Reporter:  celloexpressions         |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  4.8
Component:  Customize                |     Version:  4.7
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------

Comment (by westonruter):

 Replying to [comment:15 dlh]:
 > - If the `fallback_cb` doesn't output HTML, then the additional
 attributes in `filter_wp_nav_menu()` aren't added to the output.

 If it doesn't output HTML, then this should still work as expected. If
 you're talking about returning nothing, then essentially empty out the
 container. Otherwise, if it is outputting ''something'' I understand that
 the callback provided for `fallback_cb` needs to accept all of the
 arguments that `wp_nav_menu` would accept, since it is in fact passed all
 of those arguments. So I think it needs to be a compatible function in how
 it behaves. As a failsafe, I suppose we could modify
 `\WP_Customize_Nav_Menus::filter_wp_nav_menu()` to make sure that it
 begins with an HTML start tag.

 > - As a UX matter, do you think it makes sense to a user for the edit
 link to take them somewhere where they weren't editing the thing in the
 preview? The user would have to understand that they're "editing" the fact
 that there isn't a menu assigned to the location, as opposed to being able
 to edit the list of links output by `wp_page_menu()` or editing whatever
 the `fallback_cb` was. While the current nav menu edit links go to the
 same place as the new ones would, there's at least an "Edit Menu" link.

 The edit link will take them to the related nav menu location control,
 right? It would take them to a select dropdown that is unselected. The
 user would then see that they'd need to supply a menu. If no menus exist
 yet, then I think that's where #40104 comes into play.

 > - Presumably it's rare, but if someone already happened to provide
 support for edit links in their `fallback_cb`, then I think there would be
 two edit links.

 I think that would be rare indeed.

 Otherwise, if all that checks out, the next thing needed is to refactor
 the patch to be compatible with PHP 5.2.

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


More information about the wp-trac mailing list