Add $args parameter to wp_create_nav_menu()

[mikeschinkel]

The attached patch adds an $args parameter to wp_create_nav_menu() which simply gets passed to wp_insert_term(). This would not be used during the standard case but is important for use when a plugin uses the menu system as a building block for enhanced functionality and needs to either set a specific slug or a specific parent.

I don't need for much (any) testing so I hoping this can make it in 3.0 so I can get rid of the ugly hack in the "Microsite Editor" plugin I'm working on. Thanks. :-)

[mikeschinkel]

Adds an $args parameter for wp_create_nav_menu()

[filosofo]

I don't think the public menus API should expose or depend on the fact that menus are actually taxonomy items.

If we need to be able to set a new menu's slug, a better place is probably in wp_update_nav_menu_object (where you can currently set the parent).

[mikeschinkel]

Replying to filosofo:

I don't think the public menus API should expose or depend on the fact that menus are actually taxonomy items.

If we need to be able to set a new menu's slug, a better place is probably in wp_update_nav_menu_object (where you can currently set the parent).

Well now that you mention it....

I agree, but let me tell you why I need this and maybe you can give me some direction, i.e. suggesting another ticket+patch or agreeing that this is after all the best solution (note I'm trying to get it into WP3.0...)

I am building a "microsite" plugin for a client and I'm hoping to release as GPL it if I can get client approval after the project is over. The idea is that a website maintained by one group (let's assume the plugins is for use by hospital websites) and would have a list of people (i.e. lets assume we have a "doctor" post type) and then each post of that post type (i.e. each doctor) would have their own microsite. The microsite editor makes it simple for the web developer to include a list of predefined types of pages and then let the website administrator quickly assign custom menus for each doctor (this is the client's design; as such let's take on face value.)

The new nav menus in WP 3.0 work brilliantly for this use-case.

Unfortunately there are some problems that surface too. Let's assume there are 100+ doctors at a given hospital (this software is to be used by multiple customers, not just one website.) That results in over 100 menus showing up in the editor and it is simply not workable. What's more, those menus need not to be allowed to have menu options the microsite editor does not support. So I need a way to hide those menus from the new menu editor in WordPress since my microsite editor can handle editing those menus and WordPress' menu editor would corrupt them for my use anyway.

Looking through the code the only way I've identified to filter out my microsite menus from having them displayed in WordPress' menu editor, and here's the irony given your response is to add a SQL WHERE clause using the list_terms_exclusions hook like so:

add_filter('list_terms_exclusions','microsite_list_terms_exclusions',10,2);
function my_list_terms_exclusions($exclusions, $args) {

$exclusions .= " AND t.slug NOT LIKE 'microsite-menu-%'";

return $exclusions;

}

Pretty ironic that the only way to get menus to not show up in the standard editor is to violate the stated principle (which I agree with) of "not exposing a public menu API the depend on the fact that menus are actually taxonomy items", right? I guess the better ticket is to request a way to omit nav menu from displaying in the menu editor, but I figured that kind of request would almost certainly never make it into WP 3.0.

The ball is now back in your court. Thanks for playing...

[mikeschinkel]

Damn, using too many different wiki syntaxes for code formatting that I can't keep them straight...

add_filter('list_terms_exclusions','microsite_list_terms_exclusions',10,2);
function microsite_list_terms_exclusions($exclusions, $args) {
   $exclusions .= " AND t.slug NOT LIKE 'microsite-menu-%'";
   return $exclusions;
}

[mikeschinkel]

The ball is now back in your court. Thanks for playing...

BTW, wasn't being sarcastic, just asking for your response.

[filosofo]

r15112 should enable you to do what you want, right?

[mikeschinkel]

Yep, looks like it! Awesome, thanks.

3.0 I assume?

[mikeschinkel]

Spoke a tiny bit too soon.

While I can definitely accomplish what I need with this it seems like it will be rather inefficient for a large number of menus. Not sure if there's a better way or not, but my list_terms_exclusions was more efficient with larger datasets albeit breaking encapsulation. My use case here is to have a large number of menus and always filter almost everyone out.

Thoughts?

add_filter('wp_get_nav_menus','microsite_get_nav_menus');
function microsite_get_nav_menus($menus) {
	if ($GLOBALS['PHP_SELF']!='/wp-admin/nav-menus.php') {
		$new_menus = $menus;
	} else {
		$new_menus = array();
		foreach($menus as $menu) 
			if (substr($menu->slug,0,15)!='microsite-menu-')
				$new_menus[] = $menu;
	}
	return $new_menus;
}

[mikeschinkel]

Replying to mikeschinkel:

milestone changed from 3.0 to Future Release

:-(

[chriscct7]

The patch given no longer is mergable because the function described is now simply a wrapper function. For this reason, marking as needs refresh, in case it were to get reopened.

However, comment 1 suggested to use wp_update_nav_menu_object which the reporter couldn't use. However, as the function the reporter wishes to modify is now nothing more than a wrapper function for the wp_update_nav_menu_object function, this ticket doesn't make sense anymore to stay open. Recommending for close.

[wonderboymusic]

based on comment:11, seems like the original intent is no longer relevant - last meaningful discussion occurred 5 years ago