[wp-trac] [WordPress Trac] #13694: Add $args parameter to wp_create_nav_menu()

[WordPress Trac]

#13694: Add $args parameter to wp_create_nav_menu()
--------------------------+-------------------------------------------------
 Reporter:  mikeschinkel  |       Owner:                        
     Type:  defect (bug)  |      Status:  new                   
 Priority:  normal        |   Milestone:  3.0                   
Component:  Menus         |     Version:  3.0                   
 Severity:  normal        |    Keywords:  has-patch dev-feedback
--------------------------+-------------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:1 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...

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13694#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software