Administration bar

[rmccue]

It was ​recently mentioned that an administration bar similar to the one on WordPress.com should be created.

Apparently, the code that WP.com uses is pretty good, so that would be easy to use. I have, however, already started creating my own version of Viper007Bond's plugin, so I'll take responsibility for this.

Requirements

• Multi-site based
• Easy to setup, if not default
• User actions accessible
• Blog actions accessible
• Pluggable (easy for plugins to add their own items to the bar)

Pulling it off the Multisite component because while it serves more purpose in a multisite install, it needs to be useful for single site as well.

Other things that came up during IRC include integrating PressThis, QuickPress (and potentially a new function for that in the same line of comment_form() and wp_login_form()), integrating login abilities (would be an opt-in for it to show to non-logged in users), etc.

For blog actions, that includes Post Edit links. This means the theme can be agnostic for logged in users and thus makes caching easier.

• It should not be default. For WP, nothing else default and on the front end has ever been so intrusive in terms of markup, CSS, and JS as this will be. A core plugin would be great: an example of how to write something more complicated than Hello Dolly, etc.
• Don't use unnecessary JS. The WP.com bar uses JS to add hover states to create the drop-down menus. Roughly, for every browser except IE 6 you could use CSS alone for the same effect. For IE 6 use conditional comments to load a fix.
• Reduce bandwidth impact. There's been talk of loading it via XHR to help caching plugins. But that by itself is two additional server hits: the JS and then the response to the XHR. And the WP.com version also generates its CSS, of all things, dynamically.

First pass

Lot's to do still. s/wpcombar/wpadminbar/ in CSS and JS. Make sure query and cache debugging are supported before trying to create those menus. Clean up admin-bar css and try to move bits of it into static files. Add hooks so themes can add in their own workarounds (such as nobump) instead of hard-coding them.

A little CSS cleanup. Check for saved queries and cache stats support.

Those hooks will include a filter on the admin bar class, right?

The inline JS needs to be provided in a non-obscured form so as not to violate the GPL.

Please, please do not have this on by default. Especially while markup, styling, and behavior are so entangled, and it's using 71K of JS to add essentially hover pseudo-classes. As Twenty Ten shows, except for a couple of ancient browsers you can do that with a few lines of CSS.

Replying to filosofo:

Those hooks will include a filter on the admin bar class, right?

Surely.

Please, please do not have this on by default.

We haven't had that discussion yet. I think we want it built first.

Especially while markup, styling, and behavior are so entangled, and it's using 71K of JS to add essentially hover pseudo-classes. As Twenty Ten shows, except for a couple of ancient browsers you can do that with a few lines of CSS.

Then let's do it as CSS. I think we're all for paring that patch and the implementation down as much as possible, especially to be lightweight. I'd love to scrap the dynamic CSS file myself.

We'll provide a means to turn it on and off. I think it should be on by default for new blogs, at least. That can be figured out later though.

CSS and JS need a lot of cleanup, for sure. I agree with nacin that we want to get rid of as much JS as possible, lose the jQuery dependency, and make the CSS static.

OK, great. I'd be happy to help with any of that you want to shovel my way.

(In [15671]) Admin bar, first pass. see #14772

Replying to ryan:

(In [15671]) Admin bar, first pass. see #14772

In file admin-bar.php [15671] line 81 needs a path separator.

currently I am seeing:

$wp_admin_bar->add_menu( array( 'id' => 'me',
 'title' => get_avatar( $current_user->ID, 16 ),
 'href' => $wp_admin_bar->user->account_domain . 'wp-admin/profile.php' ) );

it should be:

$wp_admin_bar->add_menu( array( 'id' => 'me',
 'title' => get_avatar( $current_user->ID, 16 ),
 'href' => $wp_admin_bar->user->account_domain . '/wp-admin/profile.php' ) );

I just updated from trunk and noticed the admin bar. Feedback so far: I think it'd be great to add an "Edit Posts" link in addition to "New Post"

Regarding my comment above, something like the attached

The admin bar is showing up inside of the re-activate plugin iframe during plugin upgrade.

The id of the search form replicates the standard search form, hence causing an id clash.

Global dashboard link is showing, even though my test blog is not multisite.

The debug info is being included, along with a ton of validation errors. can they be turned off by default?

(sorry doing these as separates in case they need new tickets)

Appearance > Themes page is a bit messed up:

Undefined variable: tpage in E:\htdocs\wpbeta\wp-admin\themes.php on line 145
...
Fatal error: Call to undefined function themes_api() in E:\htdocs\wpbeta\wp-admin\includes\theme.php on line 325

Unable to choose a new theme as a result.

@elfin
Please use separate tickets for that.

Replying to Viper007Bond:

The admin bar is showing up inside of the re-activate plugin iframe during plugin upgrade.

See also #14980.

@ocean90 - all of them or just the last one?

Replying to elfin:

@ocean90 - all of them or just the last one?

Just the last one, because it isn't related to this ticket. Instead it would be appropriate on #14936, note the feature is being actively developed and the errors you're seeing are already known.

Replying to duck_:

note the feature is being actively developed and the errors you're seeing are already known.

If they are already known I don't need to re-report (do I?)

The admin bar is going to be in flux for the near future, so everyone might consider holding off on the bug reports until the features settle down.

Changing the blog(s) => site(s) to match with rest of WP!

So the attached patch above simple replaces all the text instances of blog(s) that we can see with site(s) to match in with the change that was made in WordPress 3.0! Any code instances of blog(s) have just been left!

Replying to filosofo:

The admin bar is going to be in flux for the near future, so everyone might consider holding off on the bug reports until the features settle down.

Probably a good idea ;)

I'm for having the functionality, but anchored only so it can be installed as a plugin.

syntax error, unexpected '&', expecting T_VARIABLE or '$' (in PHP5.3 environment)

I just uploaded trunk to do some testing and saw this error when I went to wp-admin.

Parse error: syntax error, unexpected '&', expecting T_VARIABLE or '$' in /homepages/3/d238924033/htdocs/trunk.lewayotte.com/wp-includes/admin-bar/admin-bar-class.php on line 120

But I just realized I was in a PHP4 environment, so you can probably ignore my patch.

Lew

FYI, I did notice a bug with the Admin bar... if you are in Dashboard -> Update (and click to update a plugin) the Admin bar shows up in the Update Plugins iframe.

Replying to layotte:

FYI, I did notice a bug with the Admin bar... if you are in Dashboard -> Update (and click to update a plugin) the Admin bar shows up in the Update Plugins iframe.

Already reported here: http://core.trac.wordpress.org/ticket/14772#comment:17

I found a bug:

First, I'm using Multisite mode of WP 3.1 alpha.
Second, when I update to the newest alpha version, I noticed that when I was in admin panel, the front-end code was loaded in. If you check the source code of admin panel page, you should understand what I mean.
And in this case, Google analysis code has been loaded with this. You should find URL contains /wp-admin/ is counted in your google analysis.

For the backend, is the existing admin bar going to be merged into the new one?

This would be very good, I think, as the new one from wp.com is more discreet and yet, it seems to me, more discoverable than the one we already had.

Besides, I hate looking at so many bars taking up so many pixels of vertical space. Browsers have their own bars too, and we can’t fill up the whole place with bars. :-D Something’s got to give.

Other than that, my concerns (dynamic CSS, jQuery dependency, option to switch on/off) were already addressed and I like the projected direction.

blogs/sites and ms-* => /network/

The above adminbarfixes.diff file sorts out my previous patch of changing instances of blog(s) to site(s) to match with WP as it stands currently, the new addition of the patch sorts the ms-*.php files and links to the correct network_admin_url(); updating the code to work with all the new 3.1 stuff in already!

See Also:

[15694]: Fix return false; for Adminbar Blog info.

[15693]: Fix profile link in admin bar. Props mellertime. Fixes #15022

(In [15695]) Do not show admin bar in update iframes. See #14772

(In [15696]) Do not load adminbar css in media uploader. See #14772

(In [15698]) get_user_metavalues(): Use cached user objects when querying for a single user, Prevents duplicate usermeta queries from Adminbar. Whitespace & s/AS/as/. See #14772

Can't believe I forgot to add myself to CC before. This is looking good so far.

Admin Bar cuts off top of Media Upload box (screenshot)

The Gravatar URL is slightly broken, as account_domain already has a trailing slash (on my install, at least).

It can be fixed by changing the following on line 81 of admin-bar.php:

$wp_admin_bar->user->account_domain . '/wp-admin/profile.php'

to

$wp_admin_bar->user->account_domain . 'wp-admin/profile.php'

with the /user/ code going in, some admin bar code was changed, patch running with latest trunk

Updated my patch with the admin bar fixes to run with the latest trunk! :)

(In [15760]) Standardise on ->user->domain and ->user->account_domain being trailingslash'd. See #14772

(In [15769]) s/blog/site/ on the admin bar code. props markmcwilliams, see #14772.

The admin footer is pushed down by the admin bar, causing scrolling.

(In [15834]) Allow turning off the admin bar via WP_SHOW_ADMIN_BAR constant, no_admin_bar() function, or show_admin_bar filter. see #14772

Currently it's hard to check (and also to debug) whether the admin bar has been enabled.

If I didn't miss something, with the current implementation we need to check for the constant and the filter. - So, I wrote the following code for one of my plugins:

function has_wp_admin_bar() {
    return ( function_exists('no_admin_bar') &&
    ( (!defined('WP_SHOW_ADMIN_BAR') && apply_filters('show_admin_bar', true) ) ||
    ( defined('WP_SHOW_ADMIN_BAR') && WP_SHOW_ADMIN_BAR) ) );
}

First of all I have to check if the admin-bar functionality is available, which I do with no_admin_bar as this function is the only one which resides in functions.php. Then I need to check if the constant has not been set and apply the filter as implemented in admin-bar.php. If the constant has been set it needs to be true.

Bottom-line: Imho we should get rid of the filter.

maybe we could also move the check to functions.php to provide a plugin-friendly

if (function_exists('show_admin_bar') && show_admin_bar())
    do_something();

(In [15862]) admin_bar_init action. see #14772

(In [15864]) Equal equal equal. see #14772

Since any modifications to show_admin_bar need to be made before the init action fires, we're a bit limited in what we can do to decide whether the admin bar should be on or off.

I'd like to be able to check the current user before deciding whether to show the bar; would it be worth reinstating the filter, and then setting show_admin_bar with whatever the filter returns?

There should be a space between the attributes on <a> in WP_Admin_Bar->recursive_render(). Patch attached.

a few lines before we exit the function with false if no user is logged in.

[15914], [15915]

Replying to willtj:

Since any modifications to show_admin_bar need to be made before the init action fires, we're a bit limited in what we can do to decide whether the admin bar should be on or off.

I'd like to be able to check the current user before deciding whether to show the bar; would it be worth reinstating the filter, and then setting show_admin_bar with whatever the filter returns?

The admin bar is hooked to init at the default priority of 10. A plugin that hooks in at priority 9 or less can access the current user and call show_admin_bar() prior to admin bar init.

Hi,

I am a wordpress user and fan since 2005. Thanks to all the team for your great work.

This is a suggestion for the admin bar css:

using "position: absolute" and "z-index" on the admin bar rather than applying a padding 28px !important to the body would make the change a bit less intrusive and can't break the layout of the theme. With this method, people would not bother you because of a wp_footer() missing from their old themes.

carmie, the problem is that there are still potentially theme elements--such as menu items--positioned at the very top of the page, and they would be inaccessible under a solely absolutely positioned admin bar.

(In [15938]) Don't show the admin bar in the plugin/theme installers. Inserts condition directly into iframe_header(). Allows show_admin_bar() to be called after init by unsetting wp_admin_bar, thus preventing render once those hooks are fired. see #14772.

The "Read Site" link should be renamed to "Visit Site" for the sake of consistency.

When doing Dashboard->Updates->Update Automatically the admin bar is replaced with 'white' space.

Replying to batmoo:

The "Read Site" link should be renamed to "Visit Site" for the sake of consistency.

One thing I forgot about changing when I did the s/blog/site changes, have now attached a patch that covers that! :)

attachment fatal.patch added

Debug bar is causing a Fatal error on a crummy shared host A client uses.. Turns out, they don't like the idea of you knowing how much memory you're using :)

Can we get an updated patch today, whatever the current state is? We've passed the initial feature freeze deadline and should have been doing usability testing by now so we could refine before code freeze.

Replying to jane:

Can we get an updated patch today, whatever the current state is? We've passed the initial feature freeze deadline and should have been doing usability testing by now so we could refine before code freeze.

I read in the #wordpress-dev IRC channel yesterday that filosofo would have a patch for this today because Ryan wanted to do a little bit of ripping to it! :)

I've cleared my schedule so I can finish my patch today. I'm pretty sure much of what I've been stripping out is what ryan is thinking of.

ajax loader from wp.com

In admin-bar.14772.diff I've cleaned up a bunch of stuff for the admin bar. adminbar-files.tar.gz has the actual files, in case that's easier to handle than a patch.

• Moved the CSS to its own files, including rtl. It's no longer dynamically generated.
• Menu nav dropdowns are handled by CSS, not JS. I've tested in all the big browsers successfully, except for IE6. I don't think it's worth messing with just for it, especially as it's had a degraded experience in WP starting with 3.0.
• JS is reduced to just a few lines, with no library dependencies.
• On the non-debug menu, JS does the following:
  • Replace the pre-filled search text.
  • scroll down for hash URL queries.
  • Append the admin bar as a child of the body element.
• I cleaned up the appearance and spacing of the code and eliminated a bunch of unnecessary logic checks.

TODO

• I didn't try to clean up the debug file. I think it looks terrible and doesn't belong in core.
• The load_user_locale_translations method in WP_Admin_Bar needs to have WP.com-specific cruft removed, but I'm not sure what the cruft was supposed to do, so I left it alone.

Merging and committing this now

(In [16038]) Admin bar cleanup. See #14772 props filosofo.
Moves CSS into seperate files.
Patch cleanup included moving function call arguments back on to one line where not necessary to split them.

(In [16039]) Strip out some junk from trunk. See #14772.

(In [16041]) Revert [16039]. Wasn't as much junk as it looked :-( See #14772.

(In [16042]) Debug should be a plugin not a core feature for now. See #14772.

Snack menu CSS seems broken for me all the menus end up overlaying in FF 3.6.12

I saw that the admin bar menu system had been shifted to CSS only. I just wanted to give a heads up - this was how it was on WordPress.com at initial launch, but it caused major usability problems.

The issue with CSS only is there is no delay on mouseover or mouseout which means there's no margin for error when using the menu. If a user hovers over a menu and accidentally rolls off it for a split second then the entire menu collapses. This caused a great deal of frustration with WordPress.com users who would try and navigated nested menus but not have the mouse accuracy required to stay on the menu.

Another major usability issue that popped up was that you needed to be very accurate when navigating to a sub-menu. If you try using a dropdown menu on the Mac (and probably windows) you can move the mouse from the parent menu item to any child menu item without the child menu closing. When only using CSS you have to make sure that you move the mouse to the end of the parent menu item, then over to the first child menu item, then down to the one you want. Users found this to be really frustrating as you naturally move your mouse directly to the child menu item.

I'm not saying that we need to add all the JS back in that was there previously, but for the sake of usability it might be good to add a JS delay if JS is turned on. If not then fall back to pure CSS.

One technique I've seen is to use transparent padding as a buffer, to prevent mouseout from killing the menu right away. It takes a bit of work to get right, though. I wouldn't mind a touch of JS to make things work well. Just no jQuery dependency.

That could definitely work and would avoid any JS. The delay could also be fairly easily be achieved without jQuery using setTimeout() and clearTimeOut() calls on the hover events.

(In [16043]) Missing part of the admin bar rework. See #14772 props filosofo.

(In [16044]) Add a todo. See #14772.

I'll make a patch for the snack menu and JS delay later today.

s/Read Site/Visit Site (patch refreshed)

I refreshed the s/Read Site/Visit Site patch to reflect the latest changes!

should be admin_url() and not admin_ur;()

Spotted a little slip-of-the-finger-coding! (Patch Above)

After the latest update, having define('WP_SHOW_ADMIN_BAR', false); hides the bar, but the space where it's supposed to be is still visible.

Replying to scribu:

After the latest update, having define('WP_SHOW_ADMIN_BAR', false); hides the bar, but the space where it's supposed to be is still visible.

Where is that happening? When is the constant being defined?

(In [16054]) Typo fix. Props markmcwilliams. see #14772

I'm defining it in wp-config.php.

It's happening everywhere in the admin.

(In [16055]) Lose the snack menu. see #14772

I removed the snack menu with the notion of making it a plugin. Some have said they'd like it in core, though. It is handy for those supporting large networks, but I don't know if that makes it core suitable. I don't have a strong preference either way.

Replying to markmcwilliams:

I refreshed the s/Read Site/Visit Site patch to reflect the latest changes!

In reference to that patch, Jane gave her approval in #wordpres-dev just now!

(In [16058]) s/Read Site/Visit Site/. Props markmcwilliams. see #14772

I like the idea of moving is_user_logged_in() into is_admin_bar_showing(). As is_user_logged_in() (pluggable.php) by default is only available after plugins_loaded has fired, we should add some hint into the docu of is_admin_bar_showing().

Another thing: I'm not sure about the priority in is_admin_bar_showing().

(1) The filter can be used to overrule the constant and the is_user_logged_in query. - In other words, should it be possible to display the admin bar without a logged in user?

(2) Doesn't it get a bit hard to test/debug if we use two different pointers (see comment:ticket:14772:50)?

admin-bar-fixes.14772.diff addresses some of the open issues:

• When value of the WP_SHOW_ADMIN_BAR constant is now respected.
• There is a 1/2 second delay when hovering over the menu, before it disappears, to address apeatling's usability concern above.
• Because that took a few more lines of JS, I moved the JS into its own file and moved the shortlink JS from inline into that file as well.
• The shortlink is now a top-level item, as requested by Jane in today's dev IRC chat.
• The admin bar does not appear on non-multisite admin pages, as requested by Jane.

(In [16070]) More admin bar updates. See #14772 props filosofo.
Moves js out into seperate file.
Respects WP_SHOW_ADMIN_BAR.
Moved shortlink to top-level
Removed admin bar from non-multisite admin pages.
Set eol-style on new files.

(In [16071]) If someone has defined WP_SHOW_ADMIN_BAR it wins period. Otherwise we break for things like XMLRPC which disable this always. See #14772.

(In [16072]) We never want an admin bar on an APP request either. See #14772.

Someone needs to test APP and check this hasn't broken anything.
I've fixed XMLRPC a couple of times recently because although we were not outputting anything we were calling functions which will notice when XMLRPC is defined

Viper007Bond's WordPress Admin Bar

There have been requests that the style used by Viper007Bond's plugin would be better suited than the wp.com style, especially for single blog installs. Attached is a screenshot of what it looks like. Basically, it shows the admin menus in the admin bar.

Replying to ryan:

There have been requests that the style used by Viper007Bond's plugin would be better suited than the wp.com style, especially for single blog installs. Attached is a screenshot of what it looks like. Basically, it shows the admin menus in the admin bar.

If we are going to show the menus then I think the snack menu approach is much nicer that a boat load of top level menus.

(In [16074]) Fix typo. Props filosofo. see #14772

(In [16076]) Don't show a shortlink button if we don't have one. See #14772.

I think that the .com based menu has little utility for single site installs, but the viper menu isn't very scalable if you have lots of plugins that add top-level menus. Maybe a compromise would be to pick menu sections based on what people are most likely to think of/be reminded they want to do when they are looking at the live site. Maybe something like:

Username | Current Page | New Content | Comments | Appearance | Updates

where dropdowns for each have:

Username - dashboard, profile, logout
Current Page - Edit, get shortlink
New Content - New post, new page, upload, etc.
Comments - show bubble when new comments come in
Appearance - widgets, headers, etc
Updates - show bubble when new updates available

We never really did this exercise, we just made a choice between two existing admin bars. Would have been better if we'd thought more about the use cases up front. If we can't decide on best approach, I'm okay with pulling from 3.1 and working on it for 3.2.

Username | Edit Post | New Content | Comments | Appearance | Updates | Shortlink

revised suggestion following chat with rboren.

(In [16077]) Beginnings of new admin bar organization. see #14772

(In [16078]) Add Appearance menu to admin bar. see #14772

(In [16079]) Add Updates menu to admin bar. see #14772

(In [16080]) Only show it as the Global Dashboard if multisite. See #14772

I really wish, and excuse me if this is not the proper place, there was a way to target the different list items in the menu. When you have a big list with 40 sites and you for instance would like to remove the Edit Comments list item I now have to apply display:none for 40 items.

Either a way via CSS or the ability to filter out those menu items would be provide for a lot more flexibility in the admin bar.

cc

Fix comments link.

(In [16082]) Fix comments links. Props PeteMall. see #14772

(In [16083]) get_dashboard_url() and get_edit_profile_url(). Determine the appropriate dahboard for a user based on the user's blogs and the current blog. see #14696 #14772

(In [16084]) Add Network Admin link to super admin menu. Link Site Options to site-info.php. see #14772

(In [16085]) Use get_edit_profile_url(). see #14772

(In [16086]) Lose Manage Sites. see #14772

What do you think about adding some information to the bar via add_menu() without having the need to include a link? Currently I've added a div which works fine, but I need to get rid of the empty link to produce valid HTML and have links inside the div.

(In [16098]) Kill the admin-bar directory. see #14772.

14772.CPT-new-content.diff

Do two todos:

• Use proper type name in edit strings in Edit menu
• Handle CPTs, use post type object for strings in New Content menu

updated my patch comment:ticket:14772:118

(In [16132]) Use CPTs in admin bar menus. Props duck_. see #14772

When checking out the improvements to the delay for the drop down sections (admin/New Content) I see a considerable delay causing the 2 sub menus to appear on the screen at the same time. This doesn't look so good. This is perhaps compounded by the fact they appear next to each other.

Some method of fading the non highlighted sub menu would probably enhance things a little.

(In [16162]) Lose super admin bar css. No longer used. see #14772

It would be nice if the href attribute on the 'shortlink' link was the hortlink itself, rather than the canonical url of the current post.

That way one could copy the shortlink by simply right-clicking on "shortlink" and choosing "copy url" from the context menu, as well as having the option to click and open the prompt with the url.

On single-site install, should the Admin Bar only be showing on the front-end? Yet when we get to a multisite install, it shows on both the back-end and front-end?!

Replying to markmcwilliams:

On single-site install, should the Admin Bar only be showing on the front-end? Yet when we get to a multisite install, it shows on both the back-end and front-end?!

That is intended (see ​dev chat logs). I think the reason is because the admin bar adds no extra info on single site (or something like that).

Opened #15307 and 15308 to fix dev chat-mentioned admin bar bugs specifically.

Replying to duck_:

Replying to markmcwilliams:

On single-site install, should the Admin Bar only be showing on the front-end? Yet when we get to a multisite install, it shows on both the back-end and front-end?!

That is intended (see ​dev chat logs). I think the reason is because the admin bar adds no extra info on single site (or something like that).

Just thought I'd ask, and double check! :)

The "My Sites" menu is using hardcoded links to /wp-admin/ etc, instead of calling admin_url() like everything else does.

"New Content" dropdown -> "New Post" link.

Can we make the admin bar's "New Content" drop-down just a "New Post"? The drop-down is an extra click and it's annoying. The use case is new posts, not pages. (Or "Deprecated Calls," thanks to some wonky get_post_types selecting.)

Patch attached: 14772-new-post.diff​.

#15307 and #15308 have patches, FYI

any comments/decisions on my patch attachment:ticket:14772:no_link_possible.diff​ ?

following the requirements we should be Pluggable (easy for plugins to add their own items to the bar)

Replying to neoxx:

any comments/decisions on my patch attachment:ticket:14772:no_link_possible.diff​ ?

following the requirements we should be Pluggable (easy for plugins to add their own items to the bar)

What sort of things need adding without a link - feels a little edge case.
Link can always just be a js no-op

In my case I plan to extend one of my plugins to integrate a world-clock in the admin-bar. Until now I've used the Hello Dolly-method, but a direct integration would be a lot better.

Anyway, another example would a component like the search box.

Replying to westi:

What sort of things need adding without a link - feels a little edge case.
Link can always just be a js no-op

I use it to tell people when they are running my plugin in test mode, the link isn't absolutely necessary. So it's information more than anything. (but I'll probably change the primary to be a link to the settings page for the plugin). However I then need to add pure information you are in test mode and only admins can...

Make the Shortlink item link to the shortlinkinstead of the permalink

(In [16287]) Link the shortlink button to the shortlink. Props caesarsgrunt see #14772.

Make the My Sites menu items use admin_url() instead of hardcoding the url

(In [16308]) Make the My Sites menu items use admin_url() instead of hardcoding the url. Props caesarsgrunt. see #14772

(In [16309]) Register admin menus against admin_bar_menu action to be consistent with other menu hooks. see #14772

In 14772.some.tweaks.patch
fixed name length: ​http://grab.by/7lKi
fixed comments and updates bubble: ​http://grab.by/7lNJ
fixed space beetween logo and ab-me tab: ​http://grab.by/7lKo
removed some unused CSS
fixed a type
fixed RTL CSS

(In [16310]) Admin bar fixes. Props ocean90. see #14772

Replying to westi:

Replying to neoxx:

any comments/decisions on my patch attachment:ticket:14772:no_link_possible.diff​ ?

following the requirements we should be Pluggable (easy for plugins to add their own items to the bar)

What sort of things need adding without a link - feels a little edge case.
Link can always just be a js no-op

Hmm, looks like that idea with injecting information without a link didn't make it through. - What about the possibility for plugins to add some arbitrary HTML at different positions of the Admin Bar via hooks (see attachment:ticket:14772:admin_bar_inner_hooks.diff​)?

neoxx++

Replying to neoxx:

Replying to westi:

Replying to neoxx:

any comments/decisions on my patch attachment:ticket:14772:no_link_possible.diff​ ?

following the requirements we should be Pluggable (easy for plugins to add their own items to the bar)

What sort of things need adding without a link - feels a little edge case.
Link can always just be a js no-op

Hmm, looks like that idea with injecting information without a link didn't make it through. - What about the possibility for plugins to add some arbitrary HTML at different positions of the Admin Bar via hooks (see attachment:ticket:14772:admin_bar_inner_hooks.diff​)?

Why can't you use the api that is there to add things?

Replying to westi:

Replying to neoxx:

Replying to westi:

Replying to neoxx:

any comments/decisions on my patch attachment:ticket:14772:no_link_possible.diff​ ?

following the requirements we should be Pluggable (easy for plugins to add their own items to the bar)

What sort of things need adding without a link - feels a little edge case.
Link can always just be a js no-op

Hmm, looks like that idea with injecting information without a link didn't make it through. - What about the possibility for plugins to add some arbitrary HTML at different positions of the Admin Bar via hooks (see attachment:ticket:14772:admin_bar_inner_hooks.diff​)?

Why can't you use the api that is there to add things?

My reason is that I'd like to add a <div> element which doesn't fit inside a link.

My first patch was therefore meant to increase the flexibility of the admin-bar API. - That's why I proposed the optional link in my first patch.

Replying to westi:

Why can't you use the api that is there to add things?

Because it insists on wrapping everything in links.

14772.wp_admin_body_style.patch: I think we can remove the function. For admin we can use $admin_body_class and wp-admin.css and or themes can use body_class() ([16432])

There's a bit much extraneous code in the markup/css IMO, so I hashed together a quick demo of it with much simpler markup and CSS, smaller image sprite and with IE6 support:
​http://pixopoint.com/2010/11/18/wordpress-admin-bar/

There's a brief writeup about it here:
​http://pixopoint.com/2010/11/18/wordpress-admin-bar/

I don't know much about javascript so I've left out all of it apart from a suckerfish script to keep the dropdowns working in IE6.

Replying to ryanhellyer:

I don't know much about javascript so I've left out all of it apart from a suckerfish script to keep the dropdowns working in IE6.

The current script adds a "hover" class, which you should be able to use instead of the suckerfish "sfhover" for similar effect.

There are some new tickets #15507, #15308 and #15509.

Closing this messy ticket as fixed. Please create new tickets for new problems.

another ticket: #15519