[wp-trac] [WordPress Trac] #12718: Better structure for admin $menu

[WordPress Trac]

#12718: Better structure for admin $menu
-------------------------+--------------------------------------------------
 Reporter:  scribu       |       Owner:                 
     Type:  enhancement  |      Status:  assigned       
 Priority:  normal       |   Milestone:  Awaiting Triage
Component:  Plugins      |     Version:                 
 Severity:  normal       |    Keywords:                 
-------------------------+--------------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:23 scribu]:
 > Ah, another "wonderful" thing about PHP4: objects are not passed by
 reference, but are cloned. That's why we have add_action_ref_array().

 Well that's a bit of a bummer.  I'm starting to understand why people have
 been ranting about the switch for so long now.

 If that's the case I say we add the `private`s back in and even the
 `static` method unless  you see the latter as an issue?

 > I think we should either:
 >
 >  * add a big warning in the docs, signaling that this doesn't work
 properly in PHP4
 >  * punt to WP 3.2 and only commit #14666 in 3.1

 I'm good for either.  What does the core team think about adding
 PHP5-specific code right now?

 > Also, we generally use 'delete' when it's related to user data, like
 posts and comments. We use 'remove' for everything else: remove_action(),
 remove_theme_support() etc.

 Sounds good.  I'll make those changes.

 > Also, I used the terms "Menu Section" and "Menu Item" because AFAICT
 there hasn't been consistent naming and the names that have been used are
 unclear (at least to me.) If there are terms that others would prefer, I
 can change.
 >
 > We do have a naming convention:
 >
 > {{{
 > menu: a top-level item
 > submenu: an item inside a menu
 > }}}

 Ugh. Those terms were some of what caused me difficulty when I first tried
 to understand the menus, and hence why I used different terms. The
 "submenu" term is particularly problematic for me because AFAICT they are
 options, not (sub)menus. And even "menu" is not so good because isn't the
 entire thing a menu?

 ''Proposal'': Evolve these terms and make a break from the past?  After
 all, we are talking about deprecating the old architecture, why not
 deprecate the terms too?  Here are some potentials:

  - menu section, menu item
  - menu section, menu option

 And there might be others?

 I'll wait to make the "delete_*" -> "remove_*" changes until we decide on
 this.

 Also, can I lobby for deprecating the external use of the existing
 functions and moving to these or something else that is `$args` based
 rather than 6 or 7 parameters?  They include:

  - `add_menu_page()`
  - `add_object_page()`
  - `add_utility_page()`
  - `add_submenu_page()`
  - `add_management_page()`
  - `add_options_page()`
  - `add_theme_page()`
  - `add_plugins_page()`
  - `add_users_page()`
  - `add_dashboard_page()`
  - `add_posts_page()`
  - `add_media_page()`
  - `add_links_page()`
  - `add_pages_page()`
  - `add_comments_page()`
  - `add_plugins_page()`

 The new functions could call these with an ''"undocumented"'' additional
 parameter that, if not passed, would trigger a deprecated warning when
 `WP_DEBUG` is set.  Doing this could really streamline this otherwise very
 obtuse API. Thoughts?

 -Mike

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