[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