BuddyPress

In BuddyPress 1.2.5, another attempt was made to provide us all with built in hooks we can use to tap into BuddyPress’s core loading and setup processes.

These changes appear in bp-loaded.php and bp-core.php. There are now several different actions you can attach your plugin to, depending on when exactly you need to load your code.

The main action that gets this ball rolling is called ‘bp_loaded’. It is loaded very late attached to the WordPress action ‘plugins_loaded’, at priority 20. This is to allow any old plugins that used plugins loaded the opportunity to continue to load themselves ahead of BuddyPress.

You can choose to attach your functions early or late to ‘bp_loaded’ depending on your needs.

The first action attached to ‘bp_loaded’ is ‘bp_include’. This action is intended to be used for including your files, and to attach your functions to the actions that follow it.

Next up is ‘bp_setup_root_components’ which components should use if they are adding a BuddyPress root component; I.E. ‘domain.com/groups’

Next is ‘bp_setup_globals’ which is where components actually set up all of their global properties into the $bp global.

Next is ‘bp_setup_nav’ which is how you attach your components navigation to the BuddyBar and the tabbed navigation area when viewing your profile.

Next is ‘bp_setup_widgets’ which is how you tell BuddyPress that your special component comes with extra widgets.

Lastly, is our old friend ‘bp_init’. It was moved to the end of the order so that your plugins have a place to modify existing BuddyPress core components after they have completely initialized themselves and hooked into all of the previous actions.

Plugin authors, this means that you will want to pay attention to when your plugins load which pieces of code, and make sure that you are not ahead or behind the curve.

This also means that if you’re using a heavily modified BuddyPress installation, it’s possible non-compliant plugins might not behave, so as always take extreme care when upgrading your BuddyPress installation and be sure to back everything up before giving it a go.

Thanks everyone and please report any issues you have pertaining to these new actions/hooks here so I can keep track of anything major.

Thanks for the documentation, JJJ. Maybe this could be a new page on the Codex?

That’s coming next, or have at it yourself if you’d like. First I need to get some coffee.

Exciting to see this development unfold!

Would love to see a quick example

@JJJ
These changes are not committed to trunk(for 1.3). Can you please confirm the changes will be committed to the 1.3 trunk and when

@sbrajesh -

Trunk has not been synced with branch for over 2 months. With BP 1.2.5 out the door, @johnjamesjacoby has said that he will soon be merging the 1.2 branch into trunk. So, the changes discussed in this thread will see thier way into trunk.

@jeffsayre
Thanks for confirming Jeff. That’s great.
I am looking forward to it as I have a few plugins which I am developing exclusively for 1.3 branch and do not want to break it before even completeing

Bumping this thread because I just wasted half an hour not reading it carefully enough. My loader function was using bp_init, which was too late to catch bp_setup_nav. Beware!!

Can someone please change the awesome skeleton plugin to reflect these important changes – I like Boone, spent about an hour trying to work this out. Until stumbling on this thread. The skeleton loader uses bp_init to load the files, it should use bp_include and the functions in the plugin core should be updated too.

Hi Dwenaus
Sorry that we’ve let it slip — once 1.2.6 is finalised (to avoid any last-minute code changes), I’m going to update the skeleton component. And then I’ve got a really cool idea for something like a 2.0 skeleton component, which I need to run by a few people first and then I can share some details.

+1… An updated skeleton would be very handy!