The admin bar should blend in better with the new UI

[nacin]

Especially important with #17899.

[ocean90]

Related: #18253

[nacin]

In preparations for koopersmith's work here, I've attached a patch that forces the bar on in the admin, removes the UI option, and cleans out the usermeta key.

[jane]

Should we go ahead and apply @nacin's patch so that when we introduce koop's work (probably this week, it's close) that will already be in trunk?

Working on the draft UI with koop. Will be posting to UI group for some color/styling work once the draft is in so they have something to look at.

[koopersmith]

Here is a first pass at the UI. Since the admin bar is now always shown in the dashboard (#17899), we've focused on making the admin bar contextually relevant in both the front end and dashboard. On top of the reorganization, we have also merged the admin header into the admin bar.

There are several known bugs:

1. Screen Options and Help cannot be expanded simultaneously.
2. The implementation of Search is really hacky, and will break on non-English installations.
3. Several functions have been renamed or removed. These should be properly deprecated.

Both should be fixed before going into core.

Again, this is a first pass. Things will change. Freeze is fast approaching and we're not quite a quiet bunch, so let's get the ball rolling.

[scribu]

I already love it, even if I get the following warnings:

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'wp_admin_bar_blog_menu' not found or invalid function name in /wp-includes/plugin.php on line 486

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'wp_admin_bar_view_site_menu' not found or invalid function name in /wp-includes/plugin.php on 486

Also, I don't see any search input at all.

[scribu]

18197.bar.2.diff: no more warnings, but still no search input (either in FF or Chrome).

[ocean90]

scribu: On frontend you can't see it too?

[scribu]

Yes, I can see it on the front-end.

Also, the Network Admin link is completely missing.

[scribu]

And what's the deal with the link to wordpress.org in the Sites menu? It feels spammy.

[ocean90]

Yes, I can see it on the front-end.

And that's okay. Do you need the blog search in admin?

Related to Network link: #18031

[koopersmith]

Replying to ocean90:

Yes, I can see it on the front-end.

And that's okay. Do you need the blog search in admin?

We plan to remove search from the admin until we can introduce some sort of global search within the dashboard. Redirecting the user to the front end when searching from the dashboard results in an unnatural UX.

[koopersmith]

Replying to scribu:

18197.bar.2.diff: no more warnings

And yes, 18197.bar.2.diff fixes the warnings. :)

[scribu]

Cool.

So, my suggestions for the Sites menu:

• add a "Network" link at the top
• remove the link to wordpress.org

[scribu]

Also, how about removing the current site from the list of sites? All the links are already present directly on the admin bar.

[scribu]

Diff between 18197.bar.2.diff and 18197.bar.3.diff:

​https://github.com/scribu/WordPress/compare/664727fb...admin_bar%2F18197

[johnbillion]

These changes appear to assume the admin bar is always visible in the admin area. If the admin bar is disabled in the admin area then there are lots of things missing (site title, link to site, log out link).

Will the admin bar be enforced?

[scribu]

Will the admin bar be enforced?

Yes, it will always be visible in the admin area.

[jane]

The admin bar is now basically the header, so it will have the admin persistence the old header did.

[koopersmith]

In [18683]:

Admin bar UX improvements. First pass, see #18197

[koopersmith]

In [18684]:

Improve appearance of Screen Options/Help panels, see #18197.

[ocean90]

Shouldn't the Screen Options/Help panels overlay the content all the time if they are active?

When you are on top #wp-content gets padding-top, but if you scroll a little bit and open the panels again the #wp-content gets padding-top too and overlays the content.

[koopersmith]

In [18685]:

Show correct blogs in the admin bar sites menu. see #18197.

[scribu]

Koop, could you explain what the purpose of the link to wordpress.org is?

We already have a link to wordpress.org in the footer.

[ryanimel]

I second Scribu, would like to know the thinking behind the wp.org link.

I'm also attaching a screenshot of some tinkering I did with the comment counter. I wanted to see what it would look like with the comment count next to the icon rather than inside of it.

[ryanimel]

The top is the current view, the second is the same with a lot of comments, and the third is my tinkering with the icon beside the number.

[ryanimel]

I also think I prefer the logo in the admin bar sans-shadow.

[Ipstenu]

Why is "Add New..." gone from the Admin View of the bar? It's there on the front end, but was it removed from the backend due to the flyout of the side-bar now?

[koopersmith]

In [18695]:

Admin bar styles, take 1. Props iammmattthomas, see #18197.

[koopersmith]

In [18696]:

Improve comments item in admin bar. see #18197.

[johnbillion]

The admin bar in the admin area seems a little redundant now the 'Add New', 'Appearance', and 'Comments' menus have been removed. There's barely anything in it.

I can understand why they've been removed, as the links are duplicates of those available in the main menu, but I'd prefer that the admin bar is consistent on the site and in the admin area. I think the 'Add New' menu should be reinstated.

The link to wordpress.org (and the W icon) is completely pointless, as noted by several other people.

The user menu as it is introduces a regression: #15654.

[johnbillion]

Hmm, the admin bar appears to have a min-width on it, causing the user menu to move off the side of the screen when the window's smaller than about 900px. The current admin menu also has a min-width but it's not a concern as the user menu is on the left hand side.

[dougwrites]

With the new Admin Bar consolidation, the scroll bars for, and thus part of, the help tabs are not appearing on my iPad like they do for the same install on a PC. Do they rely on Javascript?

[johnbillion]

Replying to dougwrites:

With the new Admin Bar consolidation, the scroll bars for, and thus part of, the help tabs are not appearing on my iPad like they do for the same install on a PC. Do they rely on Javascript?

It's an area with an overflow scroll. You need to use two fingers to scroll these on iOS. Not particularly intuitive but I'm not aware of a way around it.

[nacin]

In [18700]:

Force the admin bar on in the admin as it is now integrated. Removes the second UI option. Leaves out the upgrade routine for now. see #18197.

[jane]

sketch of W menu

[jane]

I was thinking I'd like some of those footer links to be more noticeable/easier to get to, so your WP resources woudn't be hard to find. To wit, the W would not just have .org main page link, but docs, support, etc. See sketch.

[scribu]

A W menu and a separate My Sites menu definitely sounds like a better solution than what we have now.

[jane]

And I think My Sites might move over to the person menu.

[Ipstenu]

Moving My Sites would 'feel good' Leave the W menu for WordPress things. Though Network Admin moving would be a third move in as many major releases. I'm not sure how much that would annoy people.

Also the background needs to be a lighter color. The black right now is too dark, unless we change the font color to eee instead of ccc. The contrast is just weird and hard to read.

[saracannon]

Here it is in the same grey gradient as the highlighted menu... ​http://cl.ly/13373C41132z151W332l

It is closer but it looks kind of weird when in dashboard and the highlight is right under the bar. ​http://cl.ly/3y1u0C0E123t2Y0x2G3x

I've attached the patch...

[saracannon]

admin bar lighter grey

[helenyhou]

And here it is in a totally different vein: blue! Just uses the gradient from buttons. Looks especially nice with the beloved blue color scheme :)

• With blue admin: ​http://cl.ly/0A2F171B3I1B1w1p0124
• With gray admin: ​http://cl.ly/0s2s19043G0J1C1k2b2c
• On front, Twenty Eleven: ​http://cl.ly/2L312o0b3T2c3I1y0Z0y

[saracannon]

Here is a lighter grey version. Kind of blends in with the theme a bit....

​http://cl.ly/1D3B2e2k0n1Z3n1A0A3G

[saracannon]

lighter version of the grey admin bar

[saracannon]

reversed gradient: ​http://cl.ly/2L0e3q3s2I0x0X2s3U2p

[saracannon]

admin bar lighter grey with reversed gradient

[ocean90]

18197.remove-userinfo.patch​ will remove the old user info styles.

[brandondove]

Seems like the WordPress menu at the far left is less important on a regular basis than actions relating to the site you're working on. What about moving it to the far right and moving the profile menu to the far left with the user's gravatar like it is in 3.2?

[helenyhou]

Deep blue (button gradient) admin bar

[helenyhou]

Replying to brandondove:

Seems like the WordPress menu at the far left is less important on a regular basis than actions relating to the site you're working on. What about moving it to the far right and moving the profile menu to the far left with the user's gravatar like it is in 3.2?

+1. I know a lot of other sites keep the user menu on the right, but with the current min-width, that's a bad menu to get cut off. It could also be nice to have screen options and help back over to the right, maybe along with the W menu, and then the user menu on the far left. The Help and Screen Options links look weird when highlighted/on and partially over the left menu - being on the right could also help that and maybe use the same gray as the help/screen options panels for a tab kind of effect: ​http://cl.ly/2l3b3J1o1q3A0d0F2n0d (admin bar is still blue from my experimenting).

[saracannon]

+1 brandondove and helenyhou for screen options on the right.

[andrewryno]

Should the hover for the admin bar dropdowns be the same as the flyouts in the main menu? If the point is to make the two blend in, they should have the same hover.

[andrewryno]

+1 to screen options/help on the right as well. That's where they were initially, anyway.

[Ipstenu]

Yeah, I can't even see the color on the drop-downs unless I jack the contrast. It should be the same darkest color of the main menu flyout (fade in gradient need not apply).

(+1 to the rightside options/help as well - Howdy/per site stuff left, WP generic/same with all sites right. Do see do)

[helenyhou]

Attaching a patch that does the following:

• Moves user menu back to the far left
• Moves W over to the far right, with Screen Options and Help also over to the right (reversed in code because they are floated right)
• Makes selected menu items (Screen Options/Help) look like tabs with the flydowns
• Darkens the blue hover color, as it was near impossible to see before

No matter what the admin bar ends up looking like (blue!), these should be applicable.

[helenyhou]

Moving stuff around, slight color changes

[brandondove]

Replying to helenyhou:

• Moves user menu back to the far left

+1 for having it on the left, though I like how the W menu is small in trunk. Do we need to have "Howdy, username" in the menu? I know we've traditionally had "Howdy" somewhere in there to add some humanity, and trust me, I love it as much as the next user, but seems to make that first menu item a lot wider than it needs to be. Why are we moving away from the format we had it in 3.2?

"[gravatar] username"

seems cleaner than

"Howdy, username [gravatar]"

I think even

"[gravatar] Howdy, username"

would be better than having the gravatar in the middle

• Darkens the blue hover color, as it was near impossible to see before

+1 I didn't even realize there was a rollover.

[jane]

Everyone is debating fine points of design. The admin bar redux as it was committed was *not done*. Koop and I needed it be in trunk as much as we had finished before moving on te pointers and other new features to get the basic functionality in so we could test it at WC Portland this past weekend, which I did. We will be coming back through this week on all the stuff we added or almost added to get it closer to being "this is what we think it should be like."

I don't think we'll move the user menu back to the far left. Something to bear in mind is that a lot of comments here are comparing this to the previous iteration of the admin bar, but you should be comparing it to the previous header instead. It's not a new admin bar, it's a combination of header and admin bar. Every single install had a header before, while far fewer had the admin bar turned on, especially in wp-admin.

[kawauso]

+1 to scribu's question re: purpose of wp.org link, that's the first thing I'd be removing on any live sites since there's so much potential to accidentally click it.

Also, is there a reason that the "Network Admin: <network name>" link is a dummy link rather than linking to the main site? As a user, I expected it to retain the same behaviour as the old header link.

[DrewAPicture]

Replying to jane:

... you should be comparing it to the previous header instead. It's not a new admin bar, it's a combination of header and admin bar.

I haven't checked helenyhou's patch, but one of the workflow problems is that the 'W', Screen Options and Help would effectively be mashed up against the other action menus when left justified.

Two of those three options used to be right-justified on every single page in the dashboard. It's odd for them to change sides.

Replying to Ipstenu:

(+1 to the rightside options/help as well - Howdy/per site stuff left, WP generic/same with all sites right. Do see do)

+1 From a purely workflow-based standpoint, this just makes more organizational sense. Howdy / Gravatar and action menus on the left, Screen Options, Help (in those nifty tabs!) and 'W' menu with outside links on the right. Do see do.

My 2¢.

[Ipstenu]

Replying to jane:

... a lot of comments here are comparing this to the previous iteration of the admin bar, but you should be comparing it to the previous header instead. It's not a new admin bar, it's a combination of header and admin bar. Every single install had a header before, while far fewer had the admin bar turned on, especially in wp-admin.

By that logical track, then Screen Options belongs on the far right (so does Help) where they are today. But if you keep them and "Howdy" all lumped together, it becomes unbalanced (and would I suspect be prone to overlap/wraparound/scroll-right-itis).

[johnhennmacc]

What about getting the update "flagger" to refresh automatically once an update (plugin or theme) has been done?

[brandondove]

Replying to jane:

Everyone is debating fine points of design. The admin bar redux as it was committed was *not done*. Koop and I needed it be in trunk as much as we had finished before moving on te pointers and other new features to get the basic functionality in so we could test it at WC Portland this past weekend, which I did. We will be coming back through this week on all the stuff we added or almost added to get it closer to being "this is what we think it should be like."

Maybe I'm misreading this, but it seems like you saying no one should be discussing/adding patches for this ticket because you're not done with implementing it. I get that it's a work in progress, but there's no use going down the wrong path and wasting time if other people have valid points to consider and patches to submit. Koop invited the community to get the ball rolling, so that's what they did.

I don't think we'll move the user menu back to the far left. Something to bear in mind is that a lot of comments here are comparing this to the previous iteration of the admin bar, but you should be comparing it to the previous header instead. It's not a new admin bar, it's a combination of header and admin bar. Every single install had a header before, while far fewer had the admin bar turned on, especially in wp-admin.

Again, maybe I'm misreading this, but it seems shortsighted to completely disregard the admin bar like it never existed. It did, and it was helpful. At this point, the functionality of the new header is far more like the old admin bar. The fact that it's going to have navigation in it means that we really need to think about how that interaction goes. I understand that it's still in early development, but that's a great time to have these discussions.

[helenyhou]

Replying to jane:

Even if most users didn't have the admin bar on before (sadface, I like the admin bar), it seems like this is enough of an overall change to be able to move things around and just have users, well, get used to it. That snazzy new pointer should help, right? :)

I also think that on really wide screens (since we are also including those on the responsive end) the user menu would quickly get lost over there, and on smaller screens it could get cut off. If it's only going to contain profile and log out, then I could see it on the right even on wide screens, but if it does indeed end up containing my sites (and/or more), then it should come over to the left because it seems it would be used often. It also seems that several of us feel that the current grouping and layout just doesn’t seem to work with most people's workflows. If it's a work in progress, then we can still discuss, right?

[Otto42]

Regression: [18683] removes the admin_user_info_links filter without replacing it, breaking plugins that used it.

Possible fix: add a filter call in wp_admin_bar_my_account_menu() to allow plugins to put in their links there in that manner.

[SergeyBiryukov]

Replying to ocean90:

18197.remove-userinfo.patch​ will remove the old user info styles.

18197.remove-userinfo.2.patch​ removes them from RTL and color scheme styles as well.

[ptahdunbar]

could someone (jane?) explain the UI/UX decision behind consolidating screen meta (screen options, help) into the admin bar? I'm trying to wrap my head around this, please help :)

It wipes out an entirely working user function that just needed some love #9657, not a spike in it's prominence level.

[azaozz]

In [18730]:

Remove redundant userinfo styling, props ocean90 and SergeyBiryukov, see #18197

[vegasgeek]

I realized it's not complete, but just throwing this out there so it's in the stream. Would be really spiffy if in the W menu, if you have enough sites that they run off the bottom of the screen, perhaps it could scroll once your mouse reaches the bottom of the list.

[ChantalC]

I love the new admin bar. However the Help and Screen Settings could be better. Implemented. Something floating?

[Ipstenu]

Admin Bar pointer has no functional close button on IE 8. I know, IE 8 is out of date, but this would be really annoying really fast.

[koopersmith]

In [18776]:

Second pass, admin bar overhaul. see #18197.

[koopersmith]

I've just committed the second large pass for the admin bar. Please keep in mind that the admin bar is still incomplete. We will be running tests over the course of the next week to help determine the final outcome.

If you have UI feedback for the admin bar, please see the ​UI group thread. Thanks!

[scribu]

Since [18776], some admin bar items are overflowing:

(in Firefox 6)

[Ipstenu]

I'm not sure how that would be addressed, but there's a weird overlap on Chrome too.

When I expanded search, the last toolbar wrapped around below the W.

(Though I think Network Admin should go as a link under the Me! Icon on the right. Save space.)

[koopersmith]

Replying to scribu:

Since [18776], some admin bar items are overflowing

Confirmed and isolated to Firefox. Odd.

Replying to Ipstenu:

I'm not sure how that would be addressed, but there's a weird overlap on Chrome too.

Ipstenu, what plugin is adding the "Performance" menu?

[nacin]

Replying to koopersmith:

Replying to Ipstenu:

I'm not sure how that would be addressed, but there's a weird overlap on Chrome too.

Ipstenu, what plugin is adding the "Performance" menu?

W3 Total Cache. Looks like a simple issue of not having enough space.

The search box should ideally just drop underneath, or do so only when it has no space. I imagine the intent was for it to be as far right as possible to avoid moving other items? (Or should it just cover up items to the right?)

[ipstenu]

W3TC, that's right. The issue isn't which plugin, it's that other plugins DO add to that bar, and we should figure out something semi graceful. If I make my screen wider, it's fine.

[chrisbliss18]

Added a patch that fixes the issue that Firefox is having with words overflowing when separated by a space. Note that I saw this happen regardless of the amount of available space in the bar. Any words separated by spaces overflowed.

I think this is due to the order in which Firefox calculates box sizes. It first calculates the size of the box containing the text, applies the negative margins, and then wraps the text because it can no longer fit. This is just a guess however.

I also noticed that when plugins add additional entries to the admin bar, that they look odd due to how the search toggle has a rule that removes the right border from it. Will that rule remain as it is currently?

[helenyhou]

Replying to chrisbliss18:

Added a patch that fixes the issue that Firefox is having with words overflowing when separated by a space.

Might be better to have that as nowrap rather than pre.

[chrisbliss18]

Fixes the overflow of words separated by a space

[chrisbliss18]

Replying to helenyhou:

Might be better to have that as nowrap rather than pre.

Agreed. I updated the patch.

[SergeyBiryukov]

Had the same problem as on scribu's screenshot in Firefox 7. chrisbliss18's patch fixes that.

[koopersmith]

In [18786]:

Prevent multiple-word admin bar items from overflowing in Firefox. props chrisbliss18, helenyhou. see #18197.

[koopersmith]

In [18787]:

Add secondary section to 'Add New' admin bar menu. see #18197.

[nacin]

In [18788]:

Cleanup in wp_admin_bar_new_content_menu. current() instead of array_shift(), remove unused index 1 from the arrays, remove ?post_type=post from the Post link. see #18197.

[avcascade]

These are excellent changes. The new admin bar is useful and intuitive. It is also clean and straightforward. I was initially skeptical of the plan to put the admin bar in the backend, but it is really looking great.

The admin bar is looking all right for me in Firefox, I'm using the latest 3.3 build.

Haven't tested the new admin bar changes with plugins - like W3 Total Cache - that seems like it might be a good next step.

[johnbillion]

Seeing as they haven't been brought up yet, two issues with the admin bar in its current state:

1. Menu items added to the user profile menu do not display correctly.
2. The user profile menu shows a big blank area when avatars are not displayed.

See ​screen shot for both issues.

In addition, the user profile menu ID has changed to 'my-account' irrespective of the avatar display setting. In 3.1 it's 'my-account-with-avatar' when avatars are displayed, and 'my-account' when they're not. Is this an oversight or a change?

[Otto42]

Taking into account John's last issue first, this happens because the "my-account-secondary" item is being added too early. Both this and all the code in the wp_admin_bar_my_sites_menu() should be pushed into another action call.

Patch forthcoming.

[Otto42]

Fix problem with the Howdy admin item putting on the secondary area too early and not allowing plugins to add to the top part properly

[SergeyBiryukov]

The Codex, Support Forums and WordPress.org links should be translatable, just like in the footer and everywhere else. Done in 18197.translatable-links.patch​.

[nacin]

In [18812]:

Remove remnants of show_admin_bar_admin. see #18811, see #18197.

[toscho]

There should be a way to use the admin bar per keyboard. Right now it is completely inaccessible in Opera and Firefox. Opera shows at least a focus indicator, but the dropdowns are dead in both browsers.

[Otto42]

Any chance of getting 18197-admin-subsites.diff pushed in? This is still breaking things with plugins and making the howdy menu look stupid on the latest nightly.

[johnbillion]

Here's an interesting one. Clicking the site title menu in the admin area takes you to the site, but the dashboard menu then pops up straight away as your mouse is still over the same spot in the admin bar. It's only minor, but I wonder if there's any way to suppress that menu appearing when the mouse is over the element on page load.

[jane]

Replying to johnbillion:

I wonder if there's any way to suppress that menu appearing when the mouse is over the element on page load.

Agreed. Sub should appear when mouse moves onto item, not if already there and mousing away.

[koopersmith]

In [18888]:

Revise admin bar items based on user testing. Post at ​http://wp.me/pbNCB-qz. see #18197.

[koopersmith]

In [18898]:

Adjust admin bar item order. see #18197.

[ramiy]

Admin bar lookes broken in RTL (hebrew).

[jane]

Last round before closing ticket as fixed:

• The front-end admin bar still needs the correct dropdown from current site name before we can do beta.
• On front end, move Edit Page to be between Add New and Search.
• Under W menu in the gray part, let's make order WordPress.org, Documentation, Support Forums, Feedback (creates a hierarchy of info/activity flow; you know how i love me some information architecture).
• Under Add New, let's use same order as left nav in dash (post, media, link, page, user) and remove theme and plugin (they aren't so much add new as search and install).

[dd32]

One more set of items:

• What items should be shown in the W menu when the bar is shown on the front end, but not logged in? Should the W menu be shown at all?

Obviously the admin-related links shouldn't be shown, Westi hid most of the admin links, but the Feedback and Credits links have been added since. See ​http://dd32.id.au/ for an example

[jane]

For some reason I was thinking the admin bar stuff only showed if you were already logged in. What I see on ​http://dd32.id.au/ is different than what I see on my test site (which has no admin bar at all on front end if not already logged in).

A) If going to show it when not logged in, move Log in to the far right to be analogous with howdy/name menu.
B) If going to show it when not logged in, I would think we wouldn't show the W menu at all, because then it's like advertising, which is lame.
C) If logged in, it could either have the full set as in dash, or just the lower gray part.

[ocean90]

Jane, it's more or less a plugin. See ​http://blog.ftwr.co.uk/archives/2011/01/05/always-show-admin-bar/

By default the bar is hidden if the user isn't logged in.

[DrewAPicture]

Replying to ocean90:

Jane, it's more or less a plugin. See ​http://blog.ftwr.co.uk/archives/2011/01/05/always-show-admin-bar/

By default the bar is hidden if the user isn't logged in.

I thought the same thing as Jane, and its probably better as a plugin, since there are many installs that don't even have users. That might be a bit confusing. Good know how to enable t though.

[dd32]

By default the bar is hidden if the user isn't logged in.

Correct, However, the Admin bar can be re-used for various other purposes, and historically/currently, Cap checks/admin checks have always been performed on the entries to prevent non-accessible items being displayed in those circumstances. The new W menu doesn't follow the same conditions. (Sorry, this was really the wrong ticket to bring it up in, should've just made a new one)

[chipbennett]

Replying to koopersmith:

If you have UI feedback for the admin bar, please see the ​UI group thread. Thanks!

I'll add this comment there as well; not sure where it is more helpful.

I think that the "W" dropdown needs to be moved to the right of the Admin menu. As it is, the "W" menu dropdown obscures the Admin menu. I found that behavior to be highly disruptive (I was aiming for the Dashboard link, and accidentally moused too high).

[jane]

@chip: That would be true of any menu placed there. The answer isn't moving the menu, but refining the hover intent timing stuff, which we'll be doing all through beta1.

[chipbennett]

Replying to chipbennett:

I think that the "W" dropdown needs to be moved to the right of the Admin menu. As it is, the "W" menu dropdown obscures the Admin menu. I found that behavior to be highly disruptive (I was aiming for the Dashboard link, and accidentally moused too high).

Okay, third time's a charm. I've moved this off to the ​Alpha/Beta forum. Sorry for the in-ticket noise; I don't think I've submitted pre-release feedback before.

[roscius]

When hovering over the admin bar search link, the cursor switches to cursor:text before the search box opens. As you need to click the search title to open the box (at least in my test env Linux/Firefox), should the cursor become a pointer and then switch to cursor:text once the box is open?

[ocean90]

On frontend when hovering over an item with a submenu we haven't a delay, but on the backend there is one. The issue is that the dropdown arrows are not indicated.

[Ipstenu]

The formatting of the 'visit site' link from the Network Admin page is a bit off.

Basically the width doesn't 'match' as well as it should.

[DrewAPicture]

Question on the new "Howdy [User]" hover menu:

Is it necessary to link the "Howdy [User]" text on the admin bar to edit-profile? Since we've switched from a click-to-open event to a hover-to-open event, I've still found it hard to break the habit of clicking the text to open the menu. This is especially aggravating since I just want to click Log Out, not load the edit profile page. I feel like our less-savvy users may also have this problem.

[thee17]

The search icon on the admin bar in the front end is giving a 404 when the Twenty Eleven theme is not installed.

[toscho]

Doubled search icon in Opera

[toscho]

I think one icon is enough. ;)

[koopersmith]

In [18927]:

Improve admin bar item order for W menu, add new menu, and edit content item. see #18197.

[chrisbliss18]

Does anyone else see an issue with the way that the Search space is styled currently?

To me, there are two issues: Since the right border is missing, the Search blends in with the custom menu to the right of it. Since the size of the Search entry is independent of the size of the text in the box (the text can be much smaller or could be cut off if too long), it makes an odd gap between it and the custom menu entry to its right.

The right-border is easily taken care of by adding a ":last-child" to the selector that removes the border. I successfully tested this in Firefox 7.0, Chromium 14, Opera 11.51, and IE 9. I included a patch for this modification.

The size issue is not as easily taken care of. I know of no way to get an text input to shrink to its contents without the use of JS, which seems avoided in preference to pure CSS solutions.

[koopersmith]

In [18929]:

Add full admin menu to admin bar on front end. props azaozz. see #18197.

[johnjamesjacoby]

Regarding r18929, I have a plugin that does this and uses the actual menu instead of rebuilding only the core menu items.

​http://plugins.svn.wordpress.org/wp-snack-menu/trunk/

Problems will arise with plugins that are incorrectly using admin_menu to execute code that isn't for the admin menu, but I think that's a consequence of doing it wrong. For this to be done more cleanly, wp-admin/menu.php would need to be turned into an API and moved into wp-includes so it's available everywhere.

[nacin]

[18929] is only temporary, pending testing. If it lasts, we will indeed need a better way to do it, code-wise.

I was thinking we could possibly leverage wp-admin/menu.php, but we'll definitely want to ob_start() and ob_end_clean() before and after, to protect us from plugins doing bad things on admin_menu. However, I don't think this is safe. If anyone is using a single admin-only core function on admin_menu to check something before doing menu-related tasks, it'll fatal error. And that wouldn't be our fault.

We can move most things to wp-includes/menu.php and add a new hook plugins can switch to. Then they just need to replace "admin_men" with our new hook to get things working automatically in the admin bar.

[chrisbliss18]

I'm glad that I'm not the only one that had reservations on r18929. To me, it is opening up too much duplication of effort, requiring any future updates to the core menu system to be mirrored here.

As John brings up, it doesn't actually recreate the menu as it ignores any customization. I'm sure that all developers could start adding their own entries into the admin bar version of the menu as well, but this just creates yet even more duplication of effort, increases the odds of something messing up, and would quickly create an inconsistent experience as not everyone will update their code to do this.

This really does bring up something that has been needed for a long time, standardization of the menu system into a simple API and the migration of the code base for it to being able to run on either the front-end or the dashboard. If this is far outside the current scope, I would say to scrap this addition to the menu until it can be done properly.

[nacin]

If this is far outside the current scope, I would say to scrap this addition to the menu until it can be done properly.

The nice thing is that we can run with this for now, and fix things up later on. If the admin bar menu is not perfectly reflective of the dashboard menu, that's okay. If plugins want to go ahead and call WP_Admin_Bar::add_menu(), that's fine too -- we can later make it so this menu is 100% automated and based on the dashboard menu. Simply renaming the parent admin bar element is enough to orphan any manually added node.

[chrisbliss18]

So is the intent to get things working automatically before release or is the plan to stick with only the core menu being available at release? I ask because I want to know if this is something that a developer can take a crack at now or if such modifications would be considered too large at this stage.

I am concerned about the "we'll fix it later" route as this has happened in the past with future patches met with an attitude of "it works well enough as-is."

[azaozz]

Replying to chrisbliss18:

...
I am concerned about the "we'll fix it later" route as this has happened in the past with future patches met with an attitude of "it works well enough as-is."

As far as I understand it, the idea is to have quick access to the top level admin pages from the front-end (as a convenience). The current admin bar sub-menu doesn't include all of the default admin menu links too.

[johnbillion]

Replying to azaozz:

As far as I understand it, the idea is to have quick access to the top level admin pages from the front-end (as a convenience). The current admin bar sub-menu doesn't include all of the default admin menu links too.

Having inconsistent menus sounds like a bad idea. It's not a convenience if you go to access a certain menu or sub-menu only for it to turn out not to be there. I'm not entirely sure that the menus which were added in r18929 are necessary. If it's not a complete duplication of the admin menu structure then it introduces confusing inconsistency, and if it is then it re-introduces menu duplications that I thought we were trying to remove by restructuring the admin bar.

[ocean90]

There is a problem with secondary menu items.

Code snippet which works nice in 3.2:

function admin_bar_test() {
	global $wp_admin_bar;
	
	$wp_admin_bar->add_menu( array(
		'parent' => 'new-content',
		'title' => 'Foo Bar',
		'href' => '#'
	) );
}
add_action( 'admin_bar_menu', 'admin_bar_test', 71 );

How it looks now:

[ryan]

Network Admin submenu

[ryan]

In [18984]:

Return to snack menu instead of full menu. Experiment over. see #18197

[Viper007Bond]

It was rather nice having full admin menu access on the front end -- saved me clicks. Hopefully it makes it into 3.4, but I will run J-Trip's plugin meanwhile. :)

[azaozz]

In [19006]:

Bring the Appearance sub-menus on the front end one level up, see #18197

[azaozz]

In [19008]:

RTL CSS tweaks, see #18197

[nacin]

In [19026]:

Remove code commented out in [19006]. see #18197.

[ryan]

Outstanding issues in comments 106, 108, 110, 113 and in patch 18197-admin-subsites.diff

[nacin]

Replying to ryan:

Outstanding issues in comments 106, 108, 110, 113 and in patch 18197-admin-subsites.diff

All -- If there's anything else missed that is already covered in a comment above, please note the comment here.

If there's anything not yet covered in this ticket, please open new tickets. We're trying to tie this one off.

[ocean90]

comment:122

[vegasgeek]

Comment 68, if there are too many sites that the list runs off the bottom of the screen, the ability to have that scroll. I can move that to a new ticket for later cleanup if you'd like.

[SergeyBiryukov]

comment:89 (refreshed the patch)

[DrewAPicture]

I split my request in comment:109 out to #19075.

[ryan]

In [19102]:

Mark links to wordpress.org resources for translation. Props SergeyBiryukov. see #18197

[ryan]

In [19104]:

Network admin snack menu. see #18197

[Ipstenu]

Outstanding issue in comment 111

Replying to toscho:

Doubled search icon in Opera
I think one icon is enough. ;)

Looks like this is still happening: ​http://wordpress.org/support/topic/search-inbox-in-admin-bar-on-opera?replies=1

[koopersmith]

In [19120]:

Improve admin bar internal representation. Simpler signatures, with backwards compatibility. Add items without requiring parents to be added first. see #18197.

[duck_]

Outstanding issue with admin_user_info_links filter in comment:64.

[SergeyBiryukov]

To summarize (and probably move some issues to new tickets):

• comment:64: Regression: [18683] removes the admin_user_info_links filter without replacing it
• comment:68: "My Sites" runs off the bottom of the screen. Duplicate of #15317 and #18913
• comment:88: Problem with the Howdy admin item putting on the secondary area too early
• comment:106: The cursor switches to cursor: text before the search box opens
• comment:108: The formatting of the "Visit Site" link from the Network Admin page is a bit off
• comment:110: The search icon gives a 404 in the front end when Twenty Eleven is not installed
• comment:111: Doubled search icon in Opera
• comment:113: No separator between Search and custom items. Moved to #19126
• comment:122: Problem with secondary menu items. The snippet doesn't seem to work in trunk

[azaozz]

In [19130]:

Revert placement of Help and Screen Options to under the admin bar on the right, see #18197, see #18785

[azaozz]

In [19131]:

Revert the look and functionality of Screen Options ans Help links/tabs, see #18197, see #18785

[DrewAPicture]

Replying to azaozz:

In [19131]:

Revert the look and functionality of Screen Options ans Help links/tabs, see #18197, see #18785

This may just be me, but since we've moved the Help/Screen options tabs back out of the Admin Bar and right-justified them, shouldn't we then also flip the tabs in Help to be right aligned as well?

Now, I click the Help link and have to move my mouse all the way across to the left to change the inner tabs. It doesn't seem as intuitive as when the Help tab was directly above where the inner tabs now sit.

[nacin]

When the Help or Screen Options tabs are open, it might make sense if they become position:fixed until closed again. This allows someone to scroll down the page while using the panels as a kind of heads-up display.

[brandondove]

I just noticed this, but why do we have a different comments icon in the header than we do in the standard navigation? Seems like we should be using the same icon in the header.

[nacin]

Replying to roscius:

When hovering over the admin bar search link, the cursor switches to cursor:text before the search box opens. As you need to click the search title to open the box (at least in my test env Linux/Firefox), should the cursor become a pointer and then switch to cursor:text once the box is open?

No, that is proper behavior. Hover over any other element that can receive text (or just text), you'll get a text cursor.

[nacin]

• Opened #19136 to address comments 64, 88, and 122.
• Opened #19137 to address comment 111.
• Opened #19138 to address comment 110.
• Opened #19139 to address comment 108.
• Comment 106 was addressed in comment 146.

With that, this ticket is now closed as fixed. New tickets for all new bug reports, thanks.

[azaozz]

Replying to nacin:

Agreed, was thinking to leave the position:fixed on the help, but it looks a bit out of place for screen options and they cannot be separated at this point. Also in #wordpress-dev we decided to revert to the 3.2 styling/behavior so went with that.

[nacin]

In [19137]:

Only show #screen-meta (which encloses the panels) when a panel is showing. Otherwise there's a one-pixel gray line that's really aggravating my OCD. see #18197.

[nacin]

In [19139]:

Two style tweaks to the update nag so it blends well with help/option panels and the admin bar.

• Add a top border to it, but hide it under the admin bar. Helps appearance as the page is rendered (as admin bar is last).
• Bring the update nag slightly off center again (see [19130]) to ensure it lines up with help/options panels.

see #18197.

[DrewAPicture]

Broke comment:143 out to #19141

[duck_]

In [19142]:

Fix double border on right side of contextual help when no help sidebar exists. See #18197.

[jane]

Replying to brandondove:

I just noticed this, but why do we have a different comments icon in the header than we do in the standard navigation? Seems like we should be using the same icon in the header.

I brought up the same thing awhile back, the nav icon apparently didn't work well against the dark background. Need to ping Ben Dunkle and ask him to reconcile them and make a new sprite.

[duck_]

In [19150]:

Update wp_admin_bar_appearance_menu docs to reflect changes made by r18683 and r19006. See #18197.

[ryan]

In [19158]:

If an empty menu ID is passed, derive it from the title and issue a _doing_it_wrong() notice. see #18197

[koopersmith]

In [19196]:

Remove dead padding/margin CSS from the admin bar. These previously were used for the now-removed arrows. see #18197.

[koopersmith]

In [19261]:

Improve admin bar markup. Un-nest top level secondary menu. Remove unnecessary span. see #18197.

[koopersmith]

In [19270]:

More admin bar markup improvements. Make primary and secondary submenu groups siblings (and prevent ul nesting issues). see #18197.

[scribu]

Related: #19260

[koopersmith]

See [19320] for a fix for #19260.

[koopersmith]

In [19328]:

Allow linkless items in the admin bar. Improve non-jQuery admin bar tabbing. fixes #19277, #19149, #19164, #15519. see #18197, #19088.

[azaozz]

In [19368], Admin bar IE7, iPad and rtl refresh, see #18197

[azaozz]

In [19370], Admin bar: re-center the search box.

[koopersmith]

In [19390]:

Slight rearrangements in admin bar render logic. see #18197.

[koopersmith]

In [19391]:

Center the admin bar search item horizontally. see #18197.

[chrisbliss18]

When no sidebar is present, the styling looks off due to the tab panel content overflowing into the space where the sidebar is.

It might be possible to create some complex CSS-only solution to this, but I think a more manageable way is to simply add a class to the #contextual-help-back div when a sidebar is absent. Styling this class would then allow for expanding out the background.

I'll attach a patch showing my idea.

[chrisbliss18]

Fix styling for contextual help without a sidebar

[koopersmith]

In [19430]:

Remove help sidebar background when no sidebar exists. props chrisbliss18, see #18197, [19361].

[johnbillion]

The text in the new admin toolbar pointer says:

"Hover over the toolbar items to see what’s new."

Is "hover" a well known term outside of web development?

[toscho]

Good catch. Screenreader users will love it. :D

[johnbillion]

Replying to johnbillion:

The text in the new admin toolbar pointer says:

"Hover over the toolbar items to see what’s new."

Is "hover" a well known term outside of web development?

Sorry, wrong ticket.

[SergeyBiryukov]

#18421 was marked as a duplicate.