BuddyPress.org

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/

Looks like a cleaner way to do it than the old cold I saw DJPaul post a few months back. Is the below incorrect in some way? I’ll probably move over to this way of doing things but we’re literally just about to launch a site with bp-groupwiki and the latest buddypress/wpmu (seems fine in terms of usability):

/* Check that BuddyPress is loaded before Wiki, from DJPaul */

function wiki_load_buddypress() {

if ( function_exists( ‘bp_core_setup_globals’ ) ) {

require_once (‘bp-groupwiki-main.php’);

return true;

}

/* Get the list of active sitewide plugins */

$active_sitewide_plugins = maybe_unserialize( get_site_option( ‘active_sitewide_plugins’ ) );

if ( !isset( $active_sidewide_plugins[‘buddypress/bp-loader.php’] ) )

return false;

if ( isset( $active_sidewide_plugins[‘buddypress/bp-loader.php’] ) && !function_exists( ‘bp_core_setup_globals’ ) ) {

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

require_once (‘bp-groupwiki-main.php’);

return true;

}

return false;

}

add_action( ‘plugins_loaded’, ‘wiki_load_buddypress’, 1 );

Andy Peatling posted this code on another thread:

/*** 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 {

deactivate_plugins( __FILE__, true );

return;

}

}

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

You have to put it at the top of plugins to make sure that BuddyPress is loaded before the plugin. Does this accomplish the same thing as dpolant’s and M’s code? Are there arguments to use one instead of the other?

Haven’t had time to try it yet…

Delete the default theme from your themes directory and then rename the folder with your theme to ‘default’.

If you want to make your sub-blogs look exactly like your primary blog *and* you are using BuddyPress 1.2 Beta, then you’ll want to check out the how-to called “Building a BuddyPress Child Theme.

I’d contact the develper https://buddypress.org/developers/mariusooms/

fyi – the trunk for BP Group Blogs has not had a commit since 12/17 so take that into consideration

“Fatal error with no indication of what the error is.”

Errors are usually suppressed on the front end. did you check your server’s error logs?

“Here is my post on another thread regarding the same issue: https://buddypress.org/forums/topic/cannot-activate-bp-12-fatal-error-cannot-redeclare-bp_loader_activate”

The phrase in there with the big clue is “cannot redeclare” Which means it is being called twice.

Which means likely – stab in the dark guess here – you have two copies of the plugin.

“How come nobody can give me any insite into whats going on”

because you have two posts within 7 hours during a timeframe where a large portion of the volunteers here are sleeping. They do that sometimes.

BuddyPress Group Blog is still broken for me …

Could you or someone else explain a bit more clearly how to fix it?

Thank you.

I mean where am I suppose to do this edit?

@ Chouf1 – no worries – thanks for the reply

Where is the IP (can’t be my mailhost as I didn’t enter any email details) banned? I am at work and will need to action something I am sure to get us out of the blacklist wherever it is… I will have to try your demo from home tonight in the meantime

Cheers

@ nommo, Sorry, this is because you’re using a banned IP or mail host.

Try to use something other. (you@gmail ie)

@dave It is just fine, your chat. BUT for my use, too much on the user-side. Too many options, possibilities etc… This is confusing for most of my users… (just the small-pop-up-chat is fine

@Chouf1 Hmmm… I try to view the demo but get “(My IP address) est banni ! Va voir ailleurs…”

@Dfa327 I have tried to install your BP Ajax Chat but couldn’t get it to work – when I hit the chat button I get “You’re currently logged out.”

@M – am I being partially sighted or is your chat plug-in demo not on your site?

I am currently rolling out an internal corp social network site based on MU&BP and chat would be a total boon. I don’t want to have to resort to Saleforce Chatter

I have adjusted the wp-hashcash plugin to work with buddypress signup. Here is what I did: I got the wp-hashcash plugin and I added the following code to the file:

global $bp;

// get our options
$options = wphc_option();
$spam = false;
//if( !strpos( $_SERVER[ ‘PHP_SELF’ ], ‘wp-signup.php’ ) )
//return $result;

// Check the wphc values against the last five keys
$spam = !in_array($_POST[“wphc_value”], $options[‘key’]);

if($spam){
$options[‘signups-spam’] = ((int) $options[‘signups-spam’]) + 1;
wphc_option($options);
$bp->signup->errors[‘spam’] = __(‘You did not pass a spam check. Please enable JavaScript in your browser.’);
} else {
$options[‘signups-ham’] = ((int) $options[‘signups-ham’]) + 1;
wphc_option($options);
}

}
add_action( ‘bp_signup_validate’, ‘wphc_check_signup_for_bp’);

function wphc_error_hook_register_page(){

do_action(‘bp_spam_errors’);

}
add_action(‘bp_before_register_page’, ‘wphc_error_hook_register_page’);

Then, under the line (line number about 507)

I put this line:

Then I activate the plugin. It should keep spam bots from being able to create accounts, but humans spammers can still do it. Anyway, if you can’t get it to work, let me know via PM and I will try to send you the file.

Later

I am having major problems with spam as well. Ironically it started as soon as I put my link in the showcase thread on this forum. I think the spam bots are looking there for easy targets as well.

Why do people make spambots that don’t even advertise stuff and just waste everyone’s time filling sites with meaningless crap. Is it like they are trying to sabotage Buddypress?

How does one submit domains and sites and IP addresses to spam traps.