BuddyPress.org

oups that was this ticket .. https://trac.buddypress.org/ticket/1706

here is the ticket. But 1.3 it’s not so near…

https://trac.buddypress.org/ticket/1593

If someone is able to do this before or to make a beautiful “how to” for use group api…

A plain WordPress theme won’t have any of the necessary template tags and loops and such to display your BuddyPress content. So you have to either add the functionality and templates your need to your current WordPress theme *or* use the BuddyPress default theme and rework it (via a child preferable) to make it look like your current theme.

So are you saying that I need to look at the php file that determines the layout of the forums page (in BuddyPress) and add the appropriate code to show what’s going on in bbPress?

Can you share the code for the way BuddyPress.org works right now, cuz that’s fine for me.

same purpose by me

I just want to organise my registred users on a BP groups basis, the others BP functions aren’t needed.

I’d rather not have to build a child theme, because of the many functions implemented on my actual wp theme (and my fear of CSS).

Waiting for a little tutorial on how to do that and ready to test/help.

Good luck, I’m looking for the same answer. I appreciate all the work that went into the new BP theme, but I want to use the WP theme and add content from some of the components. I sorta learned how this was done pre-1.2, but not sure how the detection works if the theme files are in the plugin folder and you’re not using BP-parent as the parent theme.

Someone will hopefully help soon.

yes, it works perfectly. Only 2 things need to be adjusted, like gigya login widget needs to be hidden once logged in, as after logging in it shows logout button in its widget also. And Avatar, if account is linked with yahoo, facebook etc, avatars need to be pulled from it instead default one. In gigya widget it shows avatar, but default buddypress doesn’t update to same.

@r-a-y

Using plugins loaded still does not promise that the user has BuddyPress installed on their site and activated on that particular blog, so you will still want to do the check for BP_VERSION.

It’s a dizzying setup, trying to make plugins off of plugins that may or may not be there, or are there but just aren’t loaded yet, or are loaded before yours because another plugin force loaded it out of order.

Going forward from BP1.2, we can avoid all of those issues. Remember too that bp_init has priorities too. If you need to make sure your plugin is loaded before any other BuddyPress extensions are, you can prioritize it’s load the same way as any other WordPress action.

@MariusOoms – no need to apologize. It’s the price we pay to use open source. If it’s a mission critical feature, upgrades can be done on a test server or backups allow for rolling back until all is good to go live. It’s appreciated that you got this plugin established. Anything you can do in the future will also be appreciated.

When upgrading for bp 1.2, take a look at JJJ’s comments regarding hooking dependent plugins in to bp_int. It sounds like it’s the preferred way (over what I posted earlier) to load bp first:

https://buddypress.org/forums/topic/important-plugin-devs-read-this

Best of luck with your move!

@nonegiven – I’m now having no problems with groupblogs. Old Group Blog pages are recognized and all the Blog Menu Options within the Group are associated with the correct group blog. I’d also love to see the groupblog function as part of the core bp.

@Andy – Still confused by your comment but it may not matter given the change JJJ has made to the trunk.

hi Ray

plugins_loaded is the standard action which gets called when all the active plugins’s source code is included(loaded) by wordpress, so It tells you that all the plugins are ready, and you can call your functions now.

The advantage of using “plugins_loaded” action is that, it is the first action hook which gets called after your(/all other active plugins source code is loaded by wordpress) , so You can be sure your code is called quiet before anything else happens.

Investigate wp-settings.php for more.

JJJ has proposed a nice solution with the bp_init action(just introduced in the r2472).

Because wordpress does not guarantees which plugin gets loaded first( it has something like, the plugins consisting of bare files are loaded first, the the plugins which are inside their own directory loaded alphabetically, AFAIK,It might have changed recently), So a plugin which is dependent on buddypress, will have many issues detecting bp is loaded or not.

So, JJJ’s solution helps there as all the buddypress methods which are called on plugins loaded action have priority less than default(less means higher priority), so if we hook to bp_init, we can be sure buddypress is loaded and you are still calling at the same action, I am already trying my hand with this, and it seems to be working,still testing though.

btw, if you have your plugins, which uses the hook “plugins_loaded” and has priority greater than 10, i.e 11 or anything else, you don’t need to worry about this change.

Is there any chance of the plugin being official adopted by Buddypress/Automattic, and therefore be supported?

It is a great idea but it is not safe to use if it is not going to supported.

Ditto, subdomains do not seem to be supported yet either.

I find that since the upgrade, even though I can now load the page by following the above, it just does not work. Old blogs are not recognised. If I post in a group, it goes into the main admin website again.

When I go to an old Group Blog page

under ‘Enable group blog’

Blog Title:

Blog Address:

Are blanked out with no titles.

Under the blog menu, there is Dashboard, Add New Post, Add New Link, Add New Page … but these link to main admin site blog not group blog.

I would not want to delete groups and have to remake them

Update:

https://trac.buddypress.org/changeset/2472/trunk

Now dependent plugins can hook their code into bp_init and know that all plugins have been loaded.

If you’re a plugin author and are writing a plugin specifically for BuddyPress you will want to load your code by doing exactly what I describe above.

@andy I have been meaning to ask you: how do I get a BP module to register as a site wide plugin so that it shows up in the site wide plugins list? BuddyPress and the example module register as site wide plugins but my own module doesn’t — it activates as a regular plugin that has to be activated for each blog within wpmu. I have followed the example model step by step. Is there some magic line of code that I’m missing?

Thanks.

For BuddyPress 1.2, I’ve been using this.

function your_custom_loader() {

// Put the code that needs BuddyPress here. This could be something like...

require_once( WP_PLUGIN_DIR . '/your-custom-plugin/your-plugin-buddypress.php' );

}



if ( defined( 'BP_VERSION' ) )

your_custom_loader();

else

add_action( 'bp_init', 'your_custom_loader' );

This way it isn’t loading any files and isn’t force loading BuddyPress; instead it’s looking to see if it’s active, and if it is your plugin loads; if it’s not it adds itself to the new bp_init action at the end of the BuddyPress load cycle, and loads then.

This method also follows the philosophy that plugins should be made for WordPress but be BuddyPress aware. This way you can tuck your BuddyPress functions and features away in a special your-plugin-buddypress.php file, and only load that file when BuddyPress is already loaded and active, and without errors.

Also, you’re not adding any overhead by doing this, other than a binary check for BP_VERSION. Your plugin will load itself as usual in the WordPress plugins screen, and will only start looking for BuddyPress code when BuddyPress tells it too. This is actually how I made the BuddyPress Backpat plugin load itself.

I usually only have trouble understand php code but this time my english (native language) is failing me… can Andy or another please interpret what plugin is being referenced as being updated for BP 1.2? Is Andy saying that the BP 1.2 plugin will, now (trunk) and in the final version, automatically load buddypress before all other plugins? If yes, the above mentioned code would no longer be needed in each buddypress dependent plugin? Sorry for being a bit ‘slow’ on this

I’ve looked through the trac and my interpretation does Not seem supported…

check out this thread:

https://buddypress.org/forums/topic/user-blogs-to-have-same-design-as-testbporg

Hope this helps.

Looks like a cleaner way to do it than the old cold I saw DJPaul post a few months back.

I hope you’re not criticising that code I posted a few months ago doesn’t work fully with the newest cutting-edge version of BuddyPress?

I’ve updated the plugin for BuddyPress 1.2, but it will only run on the trunk version until either the RC is released, or the final version.

You can change your registration slug by adding this to your wp-config.php file (above the stop editing line):

define( "BP_REGISTER_SLUG", "create-an-account" );

You can then happily upgrade without worrying if it will break.

Reference:

https://codex.buddypress.org/how-to-guides/changing-internal-configuration-settings/

I FIXED my issue by following Andy’s instructions here:

https://buddypress.org/forums/topic/important-plugin-devs-read-this

Quick solution:

Add the following to the top of groupblog.php:

/*** Make sure BuddyPress is loaded ********************************/

if ( !function_exists( 'bp_core_install' ) ) {

require_once( ABSPATH . '/wp-admin/includes/plugin.php' );

if ( is_plugin_active( 'buddypress/bp-loader.php' ) )

require_once ( WP_PLUGIN_DIR . '/buddypress/bp-loader.php' );

else {

return;

}

}

/*******************************************************************/

If you’re not using the default themes, or you haven’t created a theme that is a child of bp-sn-parent then you need to install the back compat plugin to get this back again:

https://wordpress.org/extend/plugins/buddypress-backwards-compatibility/