[wp-trac] [WordPress Trac] #19136: Secondary items should be a flag for the admin bar

WordPress Trac wp-trac at lists.automattic.com
Wed Nov 23 18:27:25 UTC 2011


#19136: Secondary items should be a flag for the admin bar
--------------------------+--------------------------
 Reporter:  nacin         |       Owner:  koopersmith
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  3.3
Component:  Admin Bar     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+--------------------------

Comment (by johnjamesjacoby):

 Replying to [comment:9 azaozz]:
 > I was with the impression that the secondary flag would be only for
 second level menus, i.e. all "top > submenu.secondary" will behave exactly
 like "top > submenu" except they will be outputted at the bottom and have
 slightly different styling. All children of submenu.secondary would
 inherit the styling.
 This is still how it works with the groups2 patch, except "levels" are
 "groups" and there is no upper limit to the number limit. Previous to this
 patch, there were only two "types" of menu stylings, and no way to
 reliably group them by ID. See below:

 > Not sure another UL was needed there at all. Seems to just make things
 complicated and more fragile.
 If it's the UL I think you're seeing, it is needed to maintain the styling
 and parentage associated with groups.

 > So the secondary flag would be valid only on the first level of submenus
 "top > submenu", and ignored on any sub-submenus, etc. So if a plugin
 decides to move it's menu and adds the flag, all children would inherit
 the styling, no additional flags needed.
 The "secondary flag" is a poor way to architect this, and actually
 perpetuates the problem you mention here. It limits any ability to
 reliably move groups of items in the future, and is a work-around approach
 similar to the rabbit-hole of the current main admin-nav.

 Implementing "true" groups rather than mimic them (numerically or
 otherwise) allows us to designate physical menu groups with valid and
 unique identifiers to *know* that a group of items always contain its
 children regardless of where it might ever be relocated in the future, up
 to and including anything that a plugin might choose to add anywhere in
 the binding process.

 ----

 After review, this patch is actually considerably smaller than it looks,
 and touches very little guts of the core API itself.

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


More information about the wp-trac mailing list