Search Results for 'change buddypress menu'
-
Search Results
-
Wait… do you mean a subnav? Like for instance, under profile, the subtabs are “Edit Profile, and Change Cignature?”
Could be done, wrap the bp_core_new_subnav_item call in a function which is hooked on xprofile_setup_nav action;
`/* Add the subnav items */
bp_core_new_subnav_item( array( ‘name’ => __( ‘My Friends’, ‘buddypress’ ), ‘slug’ => ‘my-friends’, ‘parent_url’ => $friends_link, ‘parent_slug’ => $bp->friends->slug, ‘screen_function’ => ‘friends_screen_my_friends’, ‘position’ => 10, ‘item_css_id’ => ‘friends-my-friends’ ) );
bp_core_new_subnav_item( array( ‘name’ => sprintf( __( ‘Requests (%d)‘, ‘buddypress’ ), bp_friend_get_total_requests_count() ), ‘slug’ => ‘requests’, ‘parent_url’ => $friends_link, ‘parent_slug’ => $bp->friends->slug, ‘screen_function’ => ‘friends_screen_requests’, ‘position’ => 20, ‘user_has_access’ => bp_is_my_profile() ) );if ( $bp->current_component == $bp->friends->slug ) {
if ( bp_is_my_profile() ) {
$bp->bp_options_title = __( ‘My Friends’, ‘buddypress’ );
} else {
$bp->bp_options_avatar = bp_core_fetch_avatar( array( ‘item_id’ => $bp->displayed_user->id, ‘type’ => ‘thumb’ ) );
$bp->bp_options_title = $bp->displayed_user->fullname;
}`There ya go, 2 in one!
Those plugins need to be updated for changes for WordPress 3.1. Contact the developers.
P.s. Achievements is my plugin and I’m aware
You are using a custom theme as soon as you do that you enter a new realm and need to know what you are doing, this particular theme Suffusion uses a custom menu of some description and BP directory menu items will not be included by default. BP hard codes these menus links in header.php (soon to change to WP nav menus)
You! have to do a little manual work in getting things to work and need to understand how both Suffusion and BP work, this act of trying to get BP to use any old WP theme is not a natural one.
In all honesty you have simply asked this question in entirely the wrong place – and perhaps I should have said this much earlier – The correct place to have addressed these issues would have been to the theme home, Suffusion has it’s own support and if you had asked there would probably have had this wrapped up and solved in no time. Strictly speaking this site supports BP and BP default theme it can’t be expected to support digressions and third party implementations – other than the plugins that have a group support home on the site.
I looked through suffusion support for you and quickly got an impression of what may be wrong however this is not something I ought to be doing for anyone
http://www.aquoid.com/forum/search.php?st=0&sk=t&sd=d&sr=posts&keywords=buddypress
I also have found myself torn about using pages for BP directories. In the end, though, I think it’s a compromise that works out for the better in the short- to medium-run, and does not have awful long-term consequences.
In my view, it is a gross overstatement to say that this move ‘ruins’ BP. However, there are a few things about it that are unappealing:
1) It forces the creation of what are, essentially, dummy pages – whatever content you might add to the page through the normal WP editor is totally ignored
2) Related – It uses part of the WP page infrastructure (URLs) without using others (in particular, WP page templates)Problem (1) is unappealing, but it is mitigated by a couple of points. First, the current system is not a whole lot better. Instead of having ‘dummy’ pages that you can see in the admin (like BP trunk has), the current version of BP has ‘phantom’ pages, so that when BP detects a URL like example.com/groups, it essentially hijacks the page load in order to do its own stuff. This is a bit jarring, and not at all transparent. So there is a trade-off, but it’s not all bad. Second, while the idea that ‘Pages in WordPress are supposed to be static content’ seems right to me in broad strokes, it doesn’t seem to me to be a hard-and-fast rule. Many plugins (gallery plugins, ecommerce plugins, etc) display their content by means of a shortcode that is manually inserted on a page or post, with pages being used for their pretty URLs.
On the other hand, there are some real benefits to directories-as-pages:
A) Easier URLs (as @driz has noted)
Integration into WP 3.0-type menus (this is the big one IMO)How important are things like (A) and (
? For sites maintained by folks with some PHP chops (and organizations with money to pay people with PHP chops), they could be fairly easily accomplished with BP_GROUPS_SLUG, etc, and with some other finagling. But – and this is just a guess – this profile does not match most of the users of BP. Nor should it, necessarily. To the extent that BP can be easy to use and install for people with little technical knowledge, without at the same time making it less flexible from a developer’s point of view, it should be. This change is good for end users, and is no more difficult for developers than the current technique, so it seems like a net win.Another more theoretical argument for the directories-as-pages move (especially as compared to the new admin panel @driz suggests for changing slugs) is that BP shouldn’t reproduce functionality that WP could provide, unless there is a convincing reason for doing so. Using WP pages for BP directories is a step toward greater BP-WP integration. It’s not perfect (see my problem (2) above) but it is a start.
As for custom post types: It’s likely that at least some of BP’s components will be refactored to use custom post types in the future. When that happens, part of the upgrade script will probably involve removing the dummy pages at issue here. So from the user’s point of view, the transition will be seamless.
I should say that I am in agreement with a lot of the sentiment in this thread about making BP a bit more lightweight, framework-y, and disjointed than the sometimes hulking behemoth it is now. However, that kind of transition can and probably should be gradual (at least more gradual than the 1.3 release).
