Skip to:

Opened 14 years ago

Closed 13 years ago

#2706 closed enhancement (fixed)

Support WP 3.1 adminbar

Reported by: djpaul's profile DJPaul Owned by:
Milestone: 1.5 Priority: major
Severity: Version:
Component: Core Keywords: dev-feedback close
Cc: azizur


Needs to be done in a backwards-compatible way for WP 3.0.

Attachments (1)

2706.001.diff (16.4 KB) - added by cnorris23 13 years ago.
preliminary and very rough draft

Download all attachments as: .zip

Change History (12)

#1 @boonebgorges
14 years ago

Was just poking around with it. The WP admin bar system is far nicer than ours, but building BP support into it might be too big a job for 1.3, unless someone is feeling really intrepid.

It should be easy to create an option (a constant or a filter maybe) that will allow users to choose between the two, though.

FYI: WP trunk currently simply hides the BP admin bar with CSS. Sneaky.

#2 @DJPaul
14 years ago

Does it? Where?

#3 @boonebgorges
14 years ago

My bad, it doesn't actually hide it, it just covers it up.

#4 @boonebgorges
13 years ago

(In [3619]) Creates BP_USE_WP_ADMIN_BAR constant to allow blog admins to choose between BP-native and WP 3.1 admin bar. References #2706

#5 @boonebgorges
13 years ago

  • Milestone changed from 1.3 to 1.4
  • Type changed from defect to enhancement

[3619] fixes this in a way that is sufficient for BP 1.3. By default, the WP 3.1 admin bar will not be loaded when BP is activated; the BP_USE_WP_ADMIN_BAR constant lets admins override and use the WP admin bar instead.

Moving this to a feature request for 1.4, as now the issue is integrating BP features into the new (and superior) WP admin bar API.

#6 @boonebgorges
13 years ago

(In [3722]) Modifies the way that BP hides the WP 3.1 admin bar, to keep with WP's recommendations. References #2706

#7 @cnorris23
13 years ago

  • Keywords dev-feedback added

So I'm including a rough draft of a patch to utilize the WP Admin Bar. There are two approaches that can be taken. One option is to just use the API ($wp_admin_bar->add_menu()/$wp_admin_bar->remove_menu()/various hooks) to add and remove menus however we need. The approach I've used in the patch uses the WP filter that allows you to create your own class. Extending isn't an option currently. In order to extend, we need a hook in WP to include early enough for success... Unless of course I totally missed something. I chose a new class as the course of action, because it would allow us to control the search form that's added by default, as it only searches posts and pages. It's commented out for now. There are a few design decisions that need to be made. One being the search form, and related to that is the "Random (item)" menu. On the original buddybar the random menu is aligned right. There are a few other things, but my brain is fried, and I'm sure you'll come across things. There's a lot of code cleanup that can happen. To start though, I just wanted to get it working and make sure the devs/community were okay with the approach before I went through and cleaned.

13 years ago

preliminary and very rough draft

#8 @azizur
13 years ago

  • Cc azizur added

Links on buddybar (BuddyPress 1.2.8 in sub directory install) does not work when used on WordPress 3.1 Network site.

#9 @azizur
13 years ago

When using:

define( 'BP_USE_WP_ADMIN_BAR', true );

Still outputs the CSS:

body {
    padding-top: 25px;

Which kind of pointless and leave a gap after the WordPress admin bar.

When define( 'BP_USE_WP_ADMIN_BAR', true ); used it should mean define( 'BP_DISABLE_ADMIN_BAR', true ); but not the case at the moment.

I think it makes sense to consolidate the two constants.

Last edited 13 years ago by azizur (previous) (diff)

#10 @cnorris23
13 years ago

  • Keywords close added

With recent changes in trunk, are we ready to close this?

#11 @boonebgorges
13 years ago

  • Milestone changed from 1.4 to 1.3
  • Resolution set to fixed
  • Status changed from new to closed

Good call. Let's close and iterate. Fixed in [4151].

Note: See TracTickets for help on using tickets.