Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 12 years ago

#3708 closed enhancement (fixed)

Get rid of top-level BP menu in wp-admin

Reported by: djpaul's profile DJPaul Owned by: djpaul's profile DJPaul
Milestone: 1.6 Priority: normal
Severity: normal Version:
Component: Core Keywords:
Cc:

Description

We should get rid of the top-level BP menu in wp-admin and move our pages into the Users and Settings menus (for example).

Attachments (1)

3708-1.patch (12.2 KB) - added by DJPaul 12 years ago.

Download all attachments as: .zip

Change History (12)

#1 @DJPaul
12 years ago

I have figured out an approach to do this while keeping backpat for existing plugins which add menus under the bp-general-settings page. If you have no legacy plugins, the top-level menu is removed, but if something is hooked in, then it is rendered.

#2 @boonebgorges
12 years ago

Can we have a review of the argument for why this is a good thing? Is there something more than a general "less is more" sentiment, where we try to blend into WP as much as possible?

I think there's an argument that removing the top-level menu for core components, but showing it when a third-party component needs it, will have the tendency to confuse admins.

I also think it's possible that, while core BP admin menus may have a natural home underneath other existing WP menu items, it's not clear that all plugin menus do. If the answer is simply "put it under Settings", then it seems like deprecating the standalone BP menu in favor of an already-crowded Settings menu is maybe not a clear-cut tradeoff.

Also, I wonder how this strategy jibes with 1.5's admin tabs navigation. Will the tabs remain there even if we spread the pages themselves through the other menus? If we're trying to mask the association with BuddyPress, what would be the purpose of those tabs?

Another minor issue is link backpat. If existing plugins have hardcoded links to the current settings pages, they will break if the panels are hooked to different parents.

#3 @DJPaul
12 years ago

The top-level menu is only shown if the user is running an old plugin which doesn't have its admin menus hooked elsewhere. It's there purely for backwards compatibility. WordPress has always warned plugins to consider if they *need* to create a top-level menu, or add their page into an existing menu, and that's no different for BuddyPress or any other plugin. I'm for encouraging users to not put things under a top-level BuddyPress menu, while providing compatibility for those who continue to choose to do so.

To address your concern about people hardcoding links to core menus in their own plugins, and those links being broken; they aren't broken*, somehow, and they continue to work (but the admin menu doesn't highlight the appropriate menu item -- not really a problem).
*The only exception is the "page=bp-general-settings" page, which had to be renamed to enable the neat backpat solution.

So, I'm going to attach a patch with what I've done so far, for feedback.
I've added an informative "where's my menus gone" page for anyone running legacy plugins who click on the top-level BuddyPress menu. My Achievements plugin works well to test the menu backpat, and you can also contrast against Welcome Pack (which adds a item in WP's Settings menu).

Menu locations: I've moved "Profile Fields" under Users, as that seems to make sense. For the others (components, pages, settings, forums), I've prefixed their menu item names with "BP" for now (so you can spot them easy), and have just shifted them underneath Settings for now. I'm not proposing this as final place, but it's just as far as I've got. I'm thinking maybe just add one "BuddyPress" item to the Settings menu, and then use the tabs to change the view. (It's a bit redundant to have tabs and four individual menu items, like 1.5 has).

@DJPaul
12 years ago

#4 @DJPaul
12 years ago

As an aside, we need to put in an Activity page, too. Though driven by the Akismet change, it also adds benefit to admin users to allow back-end management of activity items (just like comments).

#5 @johnjamesjacoby
12 years ago

I'd be okay with just having a BuddyPress menu item under "Settings." I think it's both a "less is more" thing, and that BuddyPress doesn't fall into fitting its menu items into the core WordPress menu-groups nearly as well as it can and should.

Long term I'd like for Activity, Groups, Friends, and Messages to also be manageable from within wp-admin, so removing the top level general "BuddyPress" menu makes way for those as well. Activity is already well on its way to being a solid first pass, and with Boone's Group's management plugin and bbPress taking over forums, we've chipped away pretty well already.

#6 @boonebgorges
12 years ago

If the plan is to move the current BP menus, as is, to Settings > BuddyPress (so that we have a tabbed interface) I think that it sounds fine to me. I haven't tested Paul's patch, though I'm assuming it'll work fine; showing the top level BP menu only when hooked by plugins sounds good enough to me. If possible, it would be nice to make the top-level BP menu item (when present) link to the correct Settings > BuddyPress; don't know if that's possible with WP's Dashboard api.

#7 @DJPaul
12 years ago

  • Owner set to DJPaul
  • Status changed from new to assigned

#8 @djpaul
12 years ago

(In [5406]) Relocates the top-level BuddyPress admin menu to under the Settings and Users menus. Maintains compatibility with third-party plugins that add their admin menus under the old top-level BP menu. See #3708.

#9 @djpaul
12 years ago

(In [5408]) In the Activity admin, fix certain activity types showing incorrect "In Reply To" information. See #3708

#10 @DJPaul
12 years ago

Whoops, the above was meant to go on #3660 - Paul bad.

#11 @DJPaul
12 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.