wp_nav_menu - Setting walker parameter affects fallback_cb

[bryanjwatson]

When using the walker parameter with wp_nav_menu and there is no menu present, wp_nav_menu falls back by default (set with fallback_cb) to wp_page_menu. It appears that the set walker also affects wp_page_menu, which in most cases breaks the output.

wp_nav_menu usage:

<?php wp_nav_menu(array('walker'=> new Walker_Nav_Menu)); ?>

Output when no menu is present (falling back on wp_page_menu):

// Formatted for readability
<div class="menu">
	<ul>
		<li id="menu-item-1" class="menu-item-1"><a></a></li>
		<li id="menu-item-2" class="menu-item-2"><a></a></li>
		<li id="menu-item-3" class="menu-item-3"><a></a></li>
	</ul>
</div>

Expected output:

// Formatted for readability
<div class="menu">
	<ul>
		<li class="page_item page-item-1"><a href="/first/" title="First">First</a></li>
		<li class="page_item page-item-2"><a href="/second/" title="Second">Second</a></li>
		<li class="page_item page-item-3"><a href="/third/" title="Third">Third</a></li>
	</ul>
</div>

As you can see, the output from wp_page_menu is getting filtered through the walker, but since the walker was designed for menus specifically, it renders the default output from wp_page_menu useless (empty tags..etc).

[bryanjwatson]

Simple patch, but unfortunately it does not account for the scenario when a function other than wp_page_menu is set as the fallback_cb parameter.

For example, this would still break:

<?php wp_nav_menu(array('fallback_cb'=>'wp_list_categories','walker'=>new Walker_Nav_Menu)); ?>

I believe the issue resides in the fact that the fallback function is inheriting the $args passed to wp_nav_menu.

Solution: Stop the $args inheritance on the fallback function, and create a new wp_nav_menu parameter to provide custom fallback args if needed. See patch 18232_v2.

[markoheijnen]

Is it really necessary to have special arguments for the fallback only for the walker? I rather would create a parameter only for setting the walker for the fallback.

[SergeyBiryukov]

Related: #24587

[huzaifaalmesbah]

Tested against trunk (7.0-alpha-61215-src).

Attempted to apply the latest patch (18232_v2.patch) using grunt patch:18232, but it does not apply at all. The patch is extremely old (~15 years) and no files match the current codebase, so all hunks were ignored.

Because the patch cannot be applied, testing is not possible.

Requesting reporter/component maintainer feedback to confirm whether this issue is still relevant in current WordPress or if it can be closed.

[bryanjwatson]

Replying to huzaifaalmesbah:

I've set the ticket to closed, as I'm sure this no longer applies to the current version of WordPress.

If this specific bug persists, a new ticket should be created featuring a more modern fix.