[wp-trac] [WordPress Trac] #36832: Refactor for class-walker-nav-menu-edit.php

[WordPress Trac]

#36832: Refactor for class-walker-nav-menu-edit.php
-------------------------+-----------------------------
 Reporter:  iamntz       |       Owner:
     Type:  enhancement  |      Status:  closed
 Priority:  normal       |   Milestone:
Component:  Taxonomy     |     Version:  trunk
 Severity:  normal       |  Resolution:  wontfix
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+-----------------------------
Changes (by boonebgorges):

 * component:  Menus => Taxonomy


Comment:

 > The reason for using add action instead calling the methods is simple:
 it provides a bigger flexibility

 Gotcha. It makes sense to try to be as flexible as reasonably possible.
 But if you only goal is to put things before and after the core-provided
 markup, it would be just as easy to extend the core class with a method
 that looks like this:

 {{{
     public function get_menu_item_title_markup( ... ) {
         parent::get_menu_item_title_markup( ... );

         // My extra stuff goes here
     }
 }}}

 A hook-based solution that would provide even greater flexibility is if
 the markup was built and then passed through a filter. This would allow
 the dev to add stuff to the beginning or end of the markup, or to do on-
 the-fly modification of the markup generated by core.

 I'm changing the status of this ticket to `maybelater`. I can see a way
 forward for a systematic rethink of the way that the `Walker` classes
 build markup, but it'll have to look something like this:

 1. Do an analysis of all core `Walker` classes, and come up with a naming
 convention and method design that can be shared as much as possible across
 the classes. It may make sense for this to be an interface rather than a
 base class.
 2. Review the various ways that `Walker` classes are being overridden in
 real-world applications, and show (a) how backward compatibility will be
 maintained even after the refactor, and/or (b) how and why backward
 compatibility will be broken.
 3. Review open, `wontfix`, and `maybelater` `Walker` related tickets
 currently in Trac - #18584 is a good place to start - and see if it's
 possible to address a number of these tickets as part of a redesign. This
 will help build a case that a refactor is worth the effort.
 4. Ensure that there's decent test coverage for the existing `Walker`
 classes. We generally test these classes indirectly, through integration
 tests for the wrapper functions (eg,
 `tests/phpunit/tests/category/wpListCategories.php` for
 `Walker_Category`). Additional test coverage can be introduced a bit at a
 time, and bits of tests can be submitted at any time through standalone
 enhancement tickets.

 Thanks for taking an interest :)

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