Skip to:

Forum Replies Created

Viewing 16 replies - 1 through 16 (of 16 total)

  • outolumo


    I put this in my functions.php:

    function bp_loggedin_user_profile_link() {
    global $bp;?>
    <a href=”‘. $bp->loggedin_user->domain . ‘” title=”profile”><?php _e( ‘My Profile’, ‘buddypress’ ) ?></a>
    <?php return;

    You can change the link text to whatever you want, I chose to use one buddypress translates by default.

    NOTE: using bp_ prefixed functions may later cause collisions.




    Yep, I did that search too, and as I didn’t find a list I made one. Then I tried to add it to the codex, but don’t really know how. I can only see the “Edit This Page”, link, but nothing happens when I click it.

    Using Firefox 3.5.3 on Windows XP.



    I just went through the default bp-sn-parent theme and harvested all the action hooks beginning with bp_ to a list. Could someone put it to the codex? This list could be useful for people developing their own BuddyPress themes. I hope I didn’t miss anything.

    Because these hooks appear in the default BuddyPress theme, some plugin developers might assume their existance in bp-themes. Therefore they should probably exist somewhere in the custom template files. Most of these are are fairly generic and could be filtered into existing themes (e.g. bp_head() could be filtered using wp_head() hook), assuming that the theme you are building on is properly saturated with hooks.

    Note that the optionsbar.php, userbar.php and plugin-template.php need to be added to your theme. I don’t know if they could be filtered.

    The notable exception being the search-login-bar and nav-items. IMO they shouldn’t be in the BuddyPress template at all. Better solution would be to have functions for search-box & login widget, and insert them to the template using tags for those. This would make them both more reusable – e.g. search-box could be re-used on search and 404 templates – and flexible, allowing to login box to appear separate from the search box. Likewise the nav-menu should be widgetized, i.e. made a function that can be called somewhere from the page.

    While not exactly a template tag issue, theme developers should be aware that the buddypress admin bar is by default activated at the wp_footer() as follows:

    add_action( ‘wp_footer’, ‘bp_core_admin_bar’, 8 );

    I’m gonna try placing the following to the functions.php:

    remove_action(‘wp_footer’, ‘bp_core_admin_bar’, 8);

    add_action( ‘i_want_it_here_tag’, ‘bp_core_admin_bar’, 8 );



    <?php do_action( ‘bp_head’ ) ?> (In the head section.)

    <?php do_action( ‘bp_before_search_login_bar’ ) ?>

    <?php do_action( ‘bp_login_bar_logged_out’ ) ?>

    <?php do_action( ‘bp_login_bar_logged_in’ ) ?>

    <?php do_action( ‘bp_search_login_bar’ ) ?>

    <?php do_action( ‘bp_after_search_login_bar’ ) ?>

    <?php do_action( ‘bp_before_header’ ) ?>

    <?php do_action( ‘bp_nav_items’ ); ?>

    <?php do_action( ‘bp_header’ ) ?>

    <?php do_action( ‘bp_after_header’ ) ?>

    <?php do_action( ‘bp_before_container’ ) ?>



    <?php do_action( ‘bp_after_container’ ) ?>

    <?php do_action( ‘bp_before_footer’ ) ?>

    <?php do_action( ‘bp_footer’ ) ?>

    <?php do_action( ‘bp_after_footer’ ) ?>


    Content wrappers: inside #container, but containing #content.


    <?php do_action( ‘bp_before_blog_home’ ) ?>

    <?php do_action( ‘bp_after_blog_home’ ) ?>


    <?php do_action( ‘bp_before_blog_single_post’ ) ?>

    <?php do_action( ‘bp_after_blog_single_post’ ) ?>


    <?php do_action( ‘bp_before_404’ ) ?>

    <?php do_action( ‘bp_after_404’ ) ?>


    <?php do_action( ‘bp_before_archive’ ) ?>

    <?php do_action( ‘bp_after_archive’ ) ?>


    <?php do_action( ‘bp_before_blog_page’ ) ?>

    <?php do_action( ‘bp_after_blog_page’ ) ?>


    <?php do_action( ‘bp_before_attachment’ ) ?><

    <?php do_action( ‘bp_after_attachment’ ) ?>


    <?php do_action( ‘bp_before_blog_links’ ) ?>

    <?php do_action( ‘bp_after_blog_links’ ) ?>


    <?php do_action( ‘bp_before_blog_search’ ) ?>

    <?php do_action( ‘bp_after_blog_search’ ) ?>


    Post wrappers – everything within the Loop. N.B. not every loop is listed here.

    index.php, single.php, archive.php, attachment.pgp, search.php

    <?php do_action( ‘bp_before_blog_post’ ) ?>

    <?php do_action( ‘bp_after_blog_post’ ) ?>


    Some specific tags allowing to replace the entire loop:


    <?php do_action( ‘bp_404’ ) ?>


    <?php do_action( ‘bp_blog_post’ ) ?>


    The mandatory Buddypress templates:


    <?php do_action( ‘bp_before_options_bar’ ) ?>

    <?php do_action( ‘bp_inside_before_options_bar’ ) ?>

    <?php do_action( ‘bp_inside_after_options_bar’ ) ?>

    <?php do_action( ‘bp_after_options_bar’ ) ?>


    <?php do_action( ‘bp_before_user_bar’ ) ?>

    <?php do_action( ‘bp_inside_before_user_bar’ ) ?>

    <?php do_action( ‘bp_inside_after_user_bar’ ) ?>

    <?php do_action( ‘bp_after_user_bar’ ) ?>


    <?php do_action(‘bp_template_content_header’) ?>

    <?php do_action(‘bp_template_title’) ?>

    <?php do_action(‘bp_template_content’) ?>


    Special templates:


    <?php do_action( ‘bp_before_blog_comment_list’ ) ?>

    <?php do_action( ‘bp_after_blog_comment_list’ ) ?>

    <?php do_action( ‘bp_before_blog_comment_form’ ) ?>

    <?php do_action( ‘bp_blog_comment_form’ ) ?>

    <?php do_action( ‘bp_after_blog_comment_form’ ) ?>


    <?php do_action( ‘bp_before_blog_search_form’ ) ?>

    <?php do_action( ‘bp_blog_search_form’ ) ?>

    <?php do_action( ‘bp_after_blog_search_form’ ) ?>


    <?php do_action( ‘bp_before_blog_sidebar’ ) ?>

    <?php do_action( ‘bp_inside_before_blog_sidebar’ ) ?>

    <?php do_action( ‘bp_inside_after_blog_sidebar’ ) ?>

    <?php do_action( ‘bp_after_blog_sidebar’ ) ?>

    More details about how these tags are applied can be found by looking at the files in the bp-sn-parent -theme.




    Yep, the template overlap is the issue, and this should a major design concern in the architecture I suggested: to design the buddypress functional theme layer in such a way that it overlaps as little a possible with different parent themes.

    And yes, this is a future release issue.



    It would seem that you have neglected to copy the appropriate BP themes from under the BP-directory to themes directory and activate them at the buddypress blog dashboard.

    Of course, having read the the documentation about installing BuddyPress, you already knew that…

    So, could you give some more detailed information about your sitution?



    This is a WPMU issue. Check this:



    Is there a workaround?



    I have the same problem. It seems to be a problem with the default theme:

    1) Buddypress deactivated, using buddypress theme – issue

    2) Buddypress activated, usibg P2 theme – no issue.



    It just occured to me, that detective’s way is the way the theme framework should be done. Here’s the deal:


    BP-Blog theme & BP-member theme. The blog theme was essentially any WP-blog theme (with minor tweaks), and the member theme contained the BP functionality. Both of them contained also their separate skins.

    Theming was possible by taking excisting WP-themes and BP-themes and skinning them for consistent look. This approach had obvious disadvangages, but the advantage of being able to start from just about any WP-theme.


    WP-SN-Parent theme is essentially a WP-theme with BP-functionality. Theming is done by childing this theme. This solves issues about non-standard theme structure, but has the downside of having problems with integrating to other themes.

    Enter Detective’s solution: in stead of two layers of BP default theme, we should have three:

    1) BP-Structure theme (structure)

    2) BP-Functional theme (pb-member theme etc. functionality)

    3) Skin (CSS+js etc)

    Each of these is the child theme of the upper.

    Now, since BP-Functional is essentially an unskinned non-complete theme (no headers or footers etc.), it can and must be childed to any theme, not only to BP-Structure. Hence it would restore the 1.0 ability to start from any WP theme, and integrate BP into that. Still it would use the Child theme functionality and live nicely within the WP theme ecosystem.

    For bp-theme authors this would mean improved flexibility: they could start by skinning (and maybe extending) the BP-Functional, or just the BP default skin. On the other hand, they could child the BP functional to some existing theme of theme framework – like Sandbox of Hybrid – and skin that.

    And the best part is that it would be backwards compatible with the 1.1 framework: the bp-sn-parent is just split into generic structure part an the bp-specific function part, and skinned to the actual default part. And any theme extending (childing) the bp-default could still be extending (childing) it.

    This kind of in-between theme is an interesting development in the design of WP-themes, kind of plugin in the theme architecture… Don’t know if it has been done before…

    Could this make it into 1.2?



    Could someone post such skeletal bp-in-between -framework to plugins or somewhere? One that:

    – could easily be childed to any WP-theme

    – is stripped from any non-bp elements? (header, footer etc.)

    – load_template()s were replaced with locate_template()s


    Or have I misunderstood something and this would be insensible?



    In the default buddypress theme, the main blog is under the link “Blog” the rest under “blogs”. (At least for me.)

    As for the columns, you can add widgets. (Go to the Dashboard, and there Appearence, Widgets).

    The appropriate widgets would probably be Recent posts and Sitewide recent posts. You may also try the RSS widget.



    I have this same issue. The blog name bears no resemblance to the username. There’s no reference to any blog in the profile fields.

    WPMU 2.8.4a

    BuddyPress 1.1

    It was not solved by itself overnight.



    Would there be any sense in allowing the Site Admin to choose which AC levels are available? E.g. only logged in users and friends?

    How about an easy way of granting access to members of a certain bp-group? This could be a special case of named users.



    Announces the immediate availability of…

    *first to thank you*



    Ok, I’ll write here a more precise description of what I did in case anyone has similar issues in the future.

    There’s no restriction in registering email as an username in WPMU. The only place I’ve had trouble with the email address as the username is BuddyPress. However, there may be other places, since the @-character is tedious.

    Anyway, since emails are unique in the installation, just like the usernames, they can be to uniquely identify the user logging in. The workaround the to problem is to use a separate username, and set the login procedure to use the email instead of username. Here’s a nice plugin for the task.

    Of course this workaround creates a bunch of problems for me in the integration, since these usernames aren’t necessarily used elsewhere and use of the emails in this fashion is really a hack, but these issues may be easier solved in the authentication code, which is the most crucial component in the integration and where I want to concentrate all my custom settings. Or else I’ll have to figure out something else later.



    That does as an workaround, thanks :)

Viewing 16 replies - 1 through 16 (of 16 total)
Skip to toolbar