Make WordPress Core

Opened 13 years ago

Closed 12 years ago

#16342 closed feature request (duplicate)

Administration Menu management abstraction

Reported by: jltallon's profile jltallon Owned by:
Milestone: Priority: normal
Severity: minor Version:
Component: Administration Keywords:
Focuses: Cc:


Beyond what add_menu_page/add_submenu_page and the plethora of add/remove/_mumble_page, sometimes there is a need to modify the menu structure which cannot be accomplished without fiddling with the $menu global.

I propose abstracting the menu building (and menu rendering!) code into some classes + wrapper funcs for compatibility.

Before finishing the patch up (in the form of a plugin for now): Shall I still allow plugins to manually fiddle with menu entries ?

Could this eventually be allowed into Core (for WP 3.2 or later)?

Even though a PHP4 compatibility wrapper can be added trivially (à la WP_Scripts) can we assume that WP3.2+ will require PHP5.2+ ?

Change History (10)

#1 @jltallon
13 years ago

  • Cc jltallon added
  • Owner jltallon deleted
  • Status changed from new to assigned

#3 @scribu
13 years ago

Even though a PHP4 compatibility wrapper can be added trivially (à la WP_Scripts) can we assume that WP3.2+ will require PHP5.2+ ?

Yes, WP 3.2 will require PHP 5.2+.

#4 @mikeschinkel
13 years ago

  • Cc mikeschinkel@… added

#5 @jltallon
13 years ago

Scribu: yes, saw it later. Thanks.
Mike, mind if I use your code as a source of inspiration ??

It's surely gonna be easier now that I can count on PHP5 being available :-)
(or, if you prefer, I wouldn't mind discussing and going at it together)

My idea is to have both a menu "manager" (for use by both Core and plugins) and a menu "renderer"(which would be used by Admin to draw the menus) -- just like the taxonomy walkers we have now.

Any input is appreciated.

#6 @mikeschinkel
13 years ago

@jltallon - Sure you can use my code, but I can tell you the core team didn't like where I was headed with it. They are wedded to the concept of "menu pages" and "submenu pages" vs. "menu sections" and "menu items." Can't say that I agree with that approach but I don't have a say in the matter.

Also, there are also still aspects of the menu system that make it extremely hard to abstract as I documented here even ignoring the obvious issues inherent in the positional architecture:

Still hoping though that @nacin will follow up on on his offer to review the above and give me some alternatives for addressing the issues I brought up there and/or acknowledge and take action on tickets #16048, #16050 and #16204 or workable alternatives.

#7 @voyagerfan5761
13 years ago

  • Cc WordPress@… added

#8 @jltallon
13 years ago

Indeed this has proven to be a major effort: not only would we need to replace the menu management internals, but also patch all the drawing/client code (got a quite complete list of these already)

I'm going to send a draft API first (hopefully tomorrow/in a couple days), since I don't really have that much time to spare --- I can't afford coding everything and then having the code thrown away :(

@nacin: can I assume that, even though the codex says to "print_r($GLOBALSmenu?)" in order to see the positions, the menu API is essentially private and can be modified??
It really is a major hassle to keep compatibility with plugins mucking up with the $menu / $submenu globals while changing the internals this much.

If, as I believe, allowing "Admin Themes" is a long-term goal (WP 4 maybe?), this might be a first step in the right direction.

My proposal so far includes the blocks:

  • Menu "manager" (including the main API)
  • Menu class ("top-level menu")
  • MenuItem class ("submenu")
  • compatibility wrappers ( add_menu_page, add_submenu_page, etc)
  • Menu "renderer" (à la category walkers)

Does this sound acceptable to you all ?

#9 @jltallon
13 years ago

@westi: would this (modulo your suggestions) be acceptable ??

#10 @helenyhou
12 years ago

  • Component changed from UI to Administration
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from assigned to closed

Duplicate of #12718.

Note: See TracTickets for help on using tickets.