[wp-trac] [WordPress Trac] #36832: Refactor for class-walker-nav-menu-edit.php
WordPress Trac
noreply at wordpress.org
Tue May 17 18:18:06 UTC 2016
#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
More information about the wp-trac
mailing list