[wp-trac] [WordPress Trac] #24587: Walker_Page and Walker_Nav_Menu not compatible

[WordPress Trac]

#24587: Walker_Page and Walker_Nav_Menu not compatible
------------------------------------------------+--------------------------
 Reporter:  geardev                             |       Owner:
     Type:  defect (bug)                        |  peterwilsoncc
 Priority:  normal                              |      Status:  assigned
Component:  Menus                               |   Milestone:  Future
 Severity:  normal                              |  Release
 Keywords:  needs-patch needs-unit-tests close  |     Version:  3.0
                                                |  Resolution:
                                                |     Focuses:
------------------------------------------------+--------------------------

Comment (by deeptiboddapati):

 To me, this is a design flaw more than a bug. We're dealing with tight
 coupling between menu item making methods and menu assemblers. If the item
 makers do it wrong, then menu makers error out.

 The crux of the problem concerns three pieces of jargon:
 Abstract Classes- implement only the invariant steps of the algorithm.
 Later versions of PHP added the
 {{{
 abstract
 }}}

 keyword and made real abstract classes.  These have abstract methods that
 subclasses '''must''' implement.

 Concrete classes- implement the abstract methods to carry out subclass-
 specific steps or variant steps of the algorithm.

 'hook operations' or 'customization hooks'- provide default behavior that
 subclasses ''can  optionally'' extend and usually do nothing by default.

 The parent WP_Nav_Walker class is pretending to be an ''abstract'' class
 when it isn't. If it was actually Abstract it would just do the steps that
 never vary, and let child classes define the abstract methods for anything
 that is variable.

 Although the start_el, end_el, end_lvl and start_lvl methods are called
 'abstract' in the documentation they are actually 'hook operations' or
 'customization hooks'.

 The issue is that child classes are acting like Wp_nav_walker is abstract
 although it's still handling variable aspects like the menu items and the
 arguments array.

 For BC we can't make the walker class **actually** abstract. But a good
 solution is providing more customization hooks for the child classes to
 define what input they are expecting.

 This is what the patch I'm uploading adds.

 If no factory methods are re-defined in child classes then it's shouldn't
 change anything. But if a particular child class is expecting something
 different like the nav_walker_class is, then it can define the factory
 methods to suit.

 I worked on this patch during WCUS 2016 contributor day :)

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