Administration Menu management abstraction

[jltallon]

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+ ?

[scribu]

This was attempted before: ​http://core.trac.wordpress.org/ticket/12718#comment:6

[scribu]

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+.

[jltallon]

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.

[mikeschinkel]

@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:

​http://wordpress.stackexchange.com/questions/7029/

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.

[jltallon]

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 ?

[jltallon]

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

[helenyhou]

Duplicate of #12718.