BuddyPress.org

https://buddypress.org/forums/topic/forum-posts-dont-display-chinese-character-correctly#post-43962

Check out some of the posts on that thread.

I think this could be the finial piece in truly bridging WP and BP.

I just gave your comment plugin a quick test on your site. Not sure where you are at in the development, but it took a minute or two before the comment showed up and I don’t see anything in my activity stream. Other than that it seemed to work fine.

One of my main concerns is what happens to all my existing comments?

What about pings/tracebacks?

Can the admin delete comments?

A recent comments widget would also be cool.

Keep up the good work!

Thanks, Boone!

Action hook firing sequence is confusing. I think the sequence of actions, and their priorities, need to be carefully looked at in BuddyPress.

By the way, I clarified my above post a little and added some additional thoughts to it while you were more than likely reading an older version. So, please reread my post above.

Okay, I’ve just gone through BP core and commented out all references to the plugins_loaded event accept for in bp-loader.php. I then refactored these references to hook into bp-init instead. All hooks worked fine accept bp-setup-nav. I had to set it to no priority or a priority lower than ten to make my navigation items show up in my plugin.

So, I outputted the various do_action arrays and discovered the issue. It is as I thought above–somewhat.

Not only does WordPress search for action calls top-down and alphabetically, it then reorders all action calls for a given hook by priority and if no priority is given, by the order in which it first came across a given action reference. Yes, I know, this is probably confusing most of you. Without seeing the output it may be too complex to visualize.

Here’s why my navigation menu was not showing up:

– All third-party plugins are now supposed to hook into the bp-init event

– The function in my plugin’s loader file that does that is called ‘BPAz_init’. It hooks into bp-init as follows:

add_action( 'bp_init', 'BPAz_init' );

– As you can see, I do not set a load priority on that action

– With the bp_setup_nav event (see line 2025 in bp-core.php) now tied to the bp-init event, instead of plugins_loaded, in my test core hack, and without setting any priority

add_action( 'bp_init', 'bp_setup_nav' );

it gets fired after my BPAz_init function and my plugin’s navigation menu appears

– But, if I set a priority below 10 for the bp_setup_nav event, my navigation fails to load. If I set a priority above 10, it loads. So,

add_action( 'bp_init', 'bp_setup_nav', 9 );

does not work, but,

add_action( 'bp_init', 'bp_setup_nav', 11);

works. My plugin’s navigation appears and functions.

So, the question is why?

Here’s the answer. It has to do with the fact that the function in my loader file that calls the bp-init event is found in a file that comes alphabetically before the file in which the function bp_setup_nav exists.

So, my function BPAz_init lives in a file found in /bp-authz/bp-authz-loader.php but function bp_setup_nav lives in /buddypress/bp-core.php. When the do_action function is processing the array, it sorts them first by priority and second by the order in which they were first loaded. Since my initialization function lives in a subdirectory that is searched before the buddypress subdirectory, my function that is hooked into the bp-init event is discovered before the bp_setup_nav action. This means that if no priorities are set for either function, things just happen to work fine by simple virtue of my plugin directory having a lower alphabetical order and thus higher search priority.

But if I set the priority for the bp_setup_nav action to be higher than ten (as in 9 or lower), then it is fired before my plugin is ever initialized and therefore my navigation menus cannot be rendered. If I set the priority for the bp_setup_nav action lower than ten (as in a number equal to or greater than 11), then my plugin is initialized before the bp_setup_nav event and my navigation menus work.

If I had not serendipitously named my file to something that has a higher alphabetical order than “buddypress”, I may never have discovered this issue. But, the moral of the story is this: the bp_setup_nav event must occur after all BP-dependent plugin’s have been initialized, otherwise their navigation menus will not appear. So, with the bp_setup_nav event tied to plugins_loaded, it fires before all BP-dependent plugin’s have been initialized. But, by setting a low-enough priority, it is possible to push that particular action of plugins_loaded to after all the BP-dependent plugin’s have been initialized. This is, of course, not the best way to do this.

As there may be other BP actions that are loaded too soon, I will need to spend a little time figuring out what this means for all the other action hooks in BuddyPress and BP-dependent plugins. The order in which an action fires can obviously be crucial. Since the firing order is based first on priority set, then on the alphabetical name of the functions that call a given hook, this can result in unexpected behavior.

Confused? Me too!

Put this in your bp-custom.php and create a file “login.php” in your custom theme diretory.

login.php must contain your custom login html.

It will restrict the access to your communitiy to logged in members and redirects automatically to your custom login page.

function restrict_access() {



global $bp, $bp_unfiltered_uri;



if (!is_user_logged_in() && (BP_REGISTER_SLUG != $bp->current_component) && (BP_LOGIN_SLUG != $bp->current_component)) {



//bp_core_redirect( $bp->root_domain );

bp_core_redirect( $bp->root_domain . '/' . BP_LOGIN_SLUG );



}

}



add_action( 'wp', 'restrict_access', 3 );



define('BP_LOGIN_SLUG', 'login');



function example_page_setup_root_component()

{

bp_core_add_root_component( BP_LOGIN_SLUG );

}

add_action( 'plugins_loaded', 'example_page_setup_root_component', 2 );



function bp_show_login_page() {

global $bp, $current_blog;



if ( $bp->current_component == BP_LOGIN_SLUG && $bp->current_action == '' ) {

// The first variable here must match the name of your template file below

bp_core_load_template( 'login', true );

}

}

add_action( 'wp', 'bp_show_login_page', 2 );

I use a slightly modified snippet of code found here:

https://buddypress.org/forums/topic/force-users-to-sign-up-before-being-able-to-see-contentmembers#post-34725

Buddypress on WordPress SU Really works for me!! I <3 Buddypress on WPSU!!!!

I’d recommend downloading BP 1.2.3 and doing a local search on the files, especially if you plan on doing any more customization – this will save you a lot of time.

That said, bp-core-templatetags.php probably has most of the functions related to this…

Okay, within BP, the plugins_loaded hook is added to nine times. I’m not positive on how WP searches for actions that are added to a given hook once fired, but I assume it is a standard directory search pattern–meaning top down, alphabetical. (Although I have not looked at function do_action to see if my assumption is correct.)

This means that for all activated plugins, once the plugins_loaded event is triggered, WP will first find the added actions to this hook in BuddyPress/bp-activity.php, then /bp-core.php, then finally bp-loader.php. After that, it will begin searching all BP subdirectories beginning with the BuddyPress//bp-activity/ directory.

What does this mean? It means that the single add_action to the plugins_loaded event in /bp-activity.php will be fired first, then the six added actions in /bp-core.php, and finally the single added action in bp-loader.php. This might be the root of the problem.

Since any added actions to the plugins_loaded event will be triggered no matter where they are (assuming a given plugin is activated), it causes an issue if crucial supporting code to a given function is not fired before. There is no reason for the plugins_loaded event to be referenced more than once within BP. The single occurrence of that in function bp_loaded is sufficient. From there all other added actions to the plugins_loaded event should be replaced with bp_init.

Also, no BP-dependent plugin should reference the plugins_loaded event because it will cause a conflict if BuddyPress is deactivated but for some reason that BP-dependent plugin is still active.

Instead, BP-dependent plugins should either reference the bp_init hook, or create their own custom hook.

Refactoring the aforementioned added actions in BP to fire on bp-init instead of plugins_loaded will more than likely not only solve the issue of the bp-set-nav hook not working, but also the bp_setup_root_components hook and the bp_setup_globals hook, and possibly any other hooks that we have not yet discovered are not working.

I also would recommend that priorities be set on all bp-init actions within BP core so as they are fired in the proper sequence and so that any future BP-dependent plugin that comes before “buddypress” alphabetically does not have any of its actions that are added to bp-init fire before others with in BP.

1 .Keep hte BP template pack active.

2. Go to Apperance / BP Compatibility and select “Disable BP Template Pack CSS”

Now, you can use your own stylesheet.

I suggest you copy the “bp.css” from the “bp-template-pack plugin” into your theme, and modify it, if you don’t want to override it.

That’s what I did.

Hope it helps.

Here’s how I do it:

Print out the Username:

echo bp_get_loggedin_user_fullname()

There is also a related function that avoids the need to ‘echo’ that function. Search your bp files for this function and it’s immediately above or below that one.

Print out a URL to their Profile page:

echo bp_core_get_userlink( bp_loggedin_user_id() )

Although I think that gives you a hyperlinked userlink – if you review that function you should be able to figure out a way to output the raw url, if that’s what you are looking for.

are you trying to display the recent activity in the group directory, underneath their info?

I just wrote a Quick Tip about this on my demo site

http://etivite.com/groups/buddypress/forum/topic/quick-tip-display-the-groups-recent-activity-on-group-directory-groups-loop/#topic

includes the source code and the call to feed_item_title()

with the method i outlined you can add in the new_forum_posts to only show that activity

My aforementioned Privacy Component will offer fine-grained filtering of any activity stream content–that is as long as the plugin developer made sure to register all the activity stream actions for their component. No need for fancy bp-custom.php functions, core hacks, and the like.

wow… nice!! Another great plugin to melt our heads.

UPDATE:

Based on a lot of feedback I’ve received, my proposal’s undergone some drastic changes — mainly support for WP without BP, and enhanced behaviour in Buddypress.

http://kunal-b.in/labs/index.php/gsoc-proposal/

Any gifts sent to me (admin) or this one specific user don’t show under gifts.

We still receive gift notification … and it shows that the gift was sent but under our gift screen it still says no gifts have been received.

I figured out a clean way to exclude blog post comments and forum replies from the main activity stream by essentially editing the bp-activity-classes.php file (not ideal, but it’s a start)

It’s a little off topic so I’ll continue the discussion on the previous thread where this came up:

https://buddypress.org/forums/topic/excluding-blog-post-comments-from-activity-stream-page

Login to the WPMU backend, navigate to “BuddyPress > Component Setup”, disable blog tracking.

Then disable blog registration.

Navigate to “Site Admin > Options”. Under “Allow new registrations”, select “Only user account can be created”.