Missing filter in wp_nav_menu()

[DreadLox]

Hello,

In order to, for example, display a portion of menu (​http://core.trac.wordpress.org/ticket/13793), a filter is missing to filter generated array of menu_items in wp_nav_menu().

The filter to be added should be before _wp_menu_item_classes_by_context( $menu_items ) in wp_nav_menu() function:

$menu_items = apply_filters( 'filter_name', $menu_items, $args );

[nacin]

Should probably also pass $menu.

[DreadLox]

Replying to nacin:

Should probably also pass $menu.

For sure.

[westi]

I don't think we should be adding filters this close to release.

We will probably go through the nav menu code in 3.1 and make it more extensible and I think this fits in best with that.

[DreadLox]

This filter should be added for 3.0.

Delivering a "new" menu system that does less that the old way to do it is just silly.

[nacin]

It's not designed to do less than the old system, or even replace the old system. It is designed to take a series of use cases and do them better than wp_page_menu() and wp_list_pages(), because customization isn't exactly easy to do in those instances. I can think of plenty of instances where the use case would be much more suited to those functions however over the custom menu system.

I am +1 to the filter, but I don't want to tie our hands further for a stronger API in a future version, so I'm deferring to westi for its inclusion.

[DreadLox]

I see, but it is spread all over on the Internet that Wordpress has a brand new great menu system.

So, I think most users and dev, will think like me "wow, no more messing up with pages, rewrite rules, crazy hacks and wp_list_pages, to have Wordpress act like a CMS !" and then realize like me "I can't filter the generated array of menu elements, bad..."

And that just because one line of code was delayed for 3.1 ... silly ...

[westi]

Replying to DreadLox:

I see, but it is spread all over on the Internet that Wordpress has a brand new great menu system.

So, I think most users and dev, will think like me "wow, no more messing up with pages, rewrite rules, crazy hacks and wp_list_pages, to have Wordpress act like a CMS !" and then realize like me "I can't filter the generated array of menu elements, bad..."

And that just because one line of code was delayed for 3.1 ... silly ...

At some point we have to draw the line and release 3.0

We are already in the Release Candidate phase and so we are only making changes to fix major bugs.

If we were to wait for every feature to be perfect we would never release.

I'm not sure that a filter here would not be the best way to display a portion of a configured menu and we try very hard to preserve backwards compatibility so I would rather us wait a bit and introduce this later than rush to get it in now just because the change looks simple.

In short, the time for enhancing 3.0 has passed, we are solely in major bug fix mode.

[DreadLox]

I see a large amount of reason to filter the generated array of menu_items.

And I am REALLY curious to know what would be "the best way to display a portion of a configured menu" in 3.0. Because for now, the fact is that I MUST hack Wordpress core to achieve it.

[DreadLox]

(sorry for subject change mistake)

[uglyrobot]

+5 on this!
I have a plugin now that has to ADD menu elements via a filter. Right now I have to use strpos and substr on the actual menu html to do it as I can't access the array.

Don't see why a simple (needed) filter can't be added to an RC.

[filosofo]

Moving to 3.0 after #wordpress-dev IRC discussion.

[automattor]

(In [15256]) Add missing filter to wp_get_nav_menu_items(). props filosofo, fixes #13858.

[DreadLox]

Great addition guys. Thanks.

[DreadLox]

In fact it doesn't solve the inability to get portion of a menu (submenu) see bug [13916]