#18197 closed task (blessed) (fixed)
The admin bar should blend in better with the new UI
Reported by: | nacin | Owned by: | koopersmith |
---|---|---|---|
Milestone: | 3.3 | Priority: | normal |
Severity: | normal | Version: | 3.3 |
Component: | UI | Keywords: | has-patch |
Focuses: | Cc: |
Description
Especially important with #17899.
Attachments (30)
Change History (201)
#5
@
13 years ago
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.
#7
@
13 years ago
- Keywords needs-ui added
- Version set to 3.3
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.
#8
@
13 years ago
- Keywords has-patch added; needs-ui removed
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:
- Screen Options and Help cannot be expanded simultaneously.
- The implementation of Search is really hacky, and will break on non-English installations.
- 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.
#9
@
13 years ago
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.
#10
follow-up:
↓ 16
@
13 years ago
18197.bar.2.diff: no more warnings, but still no search input (either in FF or Chrome).
#12
@
13 years ago
Yes, I can see it on the front-end.
Also, the Network Admin link is completely missing.
#13
@
13 years ago
And what's the deal with the link to wordpress.org in the Sites menu? It feels spammy.
#14
follow-up:
↓ 15
@
13 years ago
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
#15
in reply to:
↑ 14
@
13 years ago
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.
#16
in reply to:
↑ 10
@
13 years ago
Replying to scribu:
18197.bar.2.diff: no more warnings
And yes, 18197.bar.2.diff fixes the warnings. :)
#17
@
13 years ago
Cool.
So, my suggestions for the Sites menu:
- add a "Network" link at the top
- remove the link to wordpress.org
#18
@
13 years ago
Also, how about removing the current site from the list of sites? All the links are already present directly on the admin bar.
#19
@
13 years ago
Diff between 18197.bar.2.diff and 18197.bar.3.diff:
https://github.com/scribu/WordPress/compare/664727fb...admin_bar%2F18197
#20
@
13 years ago
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?
#21
@
13 years ago
Will the admin bar be enforced?
Yes, it will always be visible in the admin area.
#22
@
13 years ago
The admin bar is now basically the header, so it will have the admin persistence the old header did.
#26
@
13 years ago
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.
#28
@
13 years ago
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.
#29
@
13 years ago
- Cc ryan@… added
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.
@
13 years ago
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.
#30
@
13 years ago
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?
#33
@
13 years ago
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.
#34
@
13 years ago
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.
#35
follow-up:
↓ 36
@
13 years ago
- Cc heymrpro@… added
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?
#36
in reply to:
↑ 35
@
13 years ago
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.
#38
@
13 years ago
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.
#39
@
13 years ago
A W menu and a separate My Sites menu definitely sounds like a better solution than what we have now.
#42
@
13 years ago
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.
#44
@
13 years ago
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...
#45
@
13 years ago
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
#47
@
13 years ago
reversed gradient: http://cl.ly/2L0e3q3s2I0x0X2s3U2p
#48
follow-up:
↓ 65
@
13 years ago
18197.remove-userinfo.patch will remove the old user info styles.
#49
follow-up:
↓ 50
@
13 years ago
- Cc brandon@… added
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?
#50
in reply to:
↑ 49
@
13 years ago
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).
#52
@
13 years ago
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.
#53
@
13 years ago
+1 to screen options/help on the right as well. That's where they were initially, anyway.
#54
follow-up:
↓ 59
@
13 years ago
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)
#55
follow-up:
↓ 56
@
13 years ago
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.
#56
in reply to:
↑ 55
@
13 years ago
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.
#57
follow-ups:
↓ 60
↓ 62
@
13 years ago
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.
#58
follow-up:
↓ 63
@
13 years ago
- Cc kawauso added
+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.
#59
in reply to:
↑ 54
@
13 years ago
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¢.
#60
in reply to:
↑ 57
@
13 years ago
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).
#61
@
13 years ago
What about getting the update "flagger" to refresh automatically once an update (plugin or theme) has been done?
#62
in reply to:
↑ 57
@
13 years ago
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.
#63
in reply to:
↑ 58
@
13 years ago
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?
#64
@
13 years ago
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.
#65
in reply to:
↑ 48
@
13 years ago
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.
#66
@
13 years ago
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.
#68
@
13 years ago
- Cc john@… added
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.
#73
follow-up:
↓ 103
@
13 years ago
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!
#77
in reply to:
↑ 76
@
13 years ago
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?)
#78
@
13 years ago
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.
#79
follow-up:
↓ 80
@
13 years ago
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?
#80
in reply to:
↑ 79
;
follow-up:
↓ 81
@
13 years ago
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
.
#81
in reply to:
↑ 80
@
13 years ago
Replying to helenyhou:
Might be better to have that as
nowrap
rather thanpre
.
Agreed. I updated the patch.
#82
@
13 years ago
Had the same problem as on scribu's screenshot in Firefox 7. chrisbliss18's patch fixes that.
#86
@
13 years ago
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.
#87
@
13 years ago
Seeing as they haven't been brought up yet, two issues with the admin bar in its current state:
- Menu items added to the user profile menu do not display correctly.
- 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?
#88
@
13 years ago
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.
@
13 years ago
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
#89
@
13 years ago
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.
#91
@
13 years ago
- Cc info@… added
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.
#92
@
13 years ago
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.
#93
follow-up:
↓ 94
@
13 years ago
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.
#94
in reply to:
↑ 93
@
13 years ago
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.
#97
@
13 years ago
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).
#98
@
13 years ago
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
#99
@
13 years ago
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.
#100
follow-up:
↓ 101
@
13 years ago
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.
#101
in reply to:
↑ 100
@
13 years ago
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.
#102
@
13 years ago
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)
#103
in reply to:
↑ 73
;
follow-up:
↓ 105
@
13 years ago
- Cc chip@… added
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).
#104
@
13 years ago
@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.
#105
in reply to:
↑ 103
@
13 years ago
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.
#106
follow-up:
↓ 146
@
13 years ago
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?
#107
@
13 years ago
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.
#109
@
13 years ago
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.
#110
@
13 years ago
The search icon on the admin bar in the front end is giving a 404 when the Twenty Eleven theme is not installed.
#113
@
13 years ago
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.
#115
@
13 years ago
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.
#116
@
13 years ago
[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.
#117
@
13 years ago
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.
#118
@
13 years ago
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.
#119
follow-up:
↓ 120
@
13 years ago
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."
#120
in reply to:
↑ 119
;
follow-up:
↓ 121
@
13 years ago
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.
#121
in reply to:
↑ 120
@
13 years ago
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.
#122
@
13 years ago
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:
#124
@
13 years ago
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. :)
#129
follow-up:
↓ 130
@
13 years ago
Outstanding issues in comments 106, 108, 110, 113 and in patch 18197-admin-subsites.diff
#130
in reply to:
↑ 129
@
13 years ago
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.
#132
@
13 years ago
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.
#133
@
13 years ago
comment:89 (refreshed the patch)
#134
@
13 years ago
I split my request in comment:109 out to #19075.
#137
in reply to:
↑ 111
@
13 years ago
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
#139
@
13 years ago
Outstanding issue with admin_user_info_links filter in comment:64.
#140
@
13 years ago
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
#143
in reply to:
↑ 142
@
13 years ago
Replying to azaozz:
In [19131]:
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.
#144
follow-up:
↓ 148
@
13 years ago
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.
#145
follow-up:
↓ 153
@
13 years ago
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.
#146
in reply to:
↑ 106
@
13 years ago
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.
#148
in reply to:
↑ 144
@
13 years ago
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.
#151
@
13 years ago
Broke comment:143 out to #19141
#153
in reply to:
↑ 145
@
13 years ago
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.
#162
@
13 years ago
Admin bar IE7, iPad and rtl refresh, see #18197
#166
@
13 years ago
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.
#168
follow-up:
↓ 170
@
13 years ago
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?
#170
in reply to:
↑ 168
@
13 years ago
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.
Related: #18253