BuddyPress.org

When you upgrade to BP 1.2, you can use the BP backwards compatibility plugin:

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

That will probably be the easiest way to keep your template tags.

Read this blog post:

https://buddypress.org/blog/news/buddypress-1-2-beta/

Also what are these “errors” you speak of? Is it theme-related? Is it plugin-related?

Are you installing BP 1.2 beta on WPMU or standard WordPress?

When I have issues like this I open Firebug for Firefox and I can usually track down the problem.

Just change the upload path setting and filter the location, not a big deal.

Tutorial for creating BuddyPress Child Theme – https://codex.buddypress.org/how-to-guides/building-a-buddypress-child-theme/

Use Google for more info re creating WordPress Child Themes

BuddyPress Codex – https://codex.buddypress.org/

BuddyPress Components/Features – https://buddypress.org/about/

Examples of BuddyPress sites and usage – https://wordpress.org/showcase/flavor/buddypress/

In child theme’s style.css, add BuddyPress tag ala bp-classic’s style.css where at top you see

Tags: buddypress, three-columns, white, orange

I agree that privacy is a prime concern, but I think by using plugins that work to your needs is a better approach then making everything core..

To use your analogy, WordPress is an Engine in a car.. Tested to be working 100% and made sure everything is perfect…

BuddyPress is an aftermarket Turbo that a bunch of guys got working on that engine..

It’s awesome, we all want it, but its not going to be totally perfect out the gate, and in the end may make your engine blow up..

Over Time I see privacy, images, user levels, events, projects, etc. becoming core but for now the idea is a stable base we can add on to..

If anyone ever used WP 1+ the switch to 2+ was NUTS and then 2.5+ OMG..

So much of what was a “Plugin” became core, and now look at 2.9 All those image plugins, thumbnail plugins, ETC went out the window when the core worked that functionality in.

@Andy

Thanks. I can probably figure out what you meant by this last post. I’ll look for a buddypress tag in the css header of the parent/child. I agree this will probably never be ideal as anytime there is a struggle between two ‘parents.’ Code mirroring life.

To hush the “No BuddyPress theme” nag you need to add a “buddypress” tag to your theme css header.

If you want to use BuddyPress with an existing WordPress theme you need to copy over the theme files. You’ll need to adjust the HTML to match you theme though.

This is never going to be the ideal way to do things though, the best experience with BuddyPress is always going to be building a site from scratch with BuddyPress in mind.

I sorta get this, but here’s my concern. I’m using Hybrid Framework which needs to be the parent. I will make a child theme based on it. Ideally, I’d like to put the BP “stuff” in the child so upgrading Hybrid won’t screw up anything (Andy said something about this being an acceptable approach in another thread). Also, if/when Justin adds BP capabilities to Hybrid, I can just delete the BP functionality in the child.

If I do this, I probably need to take the functions/templates from BP parent and put them with WP child. I’m fine with this too (although painful on upgrade). My question is about where BP is looking for things. If it’s looking in the plugin folder and I have the files/functions in the WP child theme folder, will that work???

Before I go ripping out BP parent files and inserting them into WP child folder, I’d like to know.

Wait sorry, I was confused above. I meant I’ve updated this plugin:

https://wordpress.org/extend/plugins/external-group-blogs/

Not BP group blogs.

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.

I used it on WordPress, not WordPress MU, however I had tried for short time just to see if it registers users on WordPress MU, and It did, but further than that I have no knowledge of it.

On WordPress, it works fine, just for regular plugin search install gigya and good to go, It will register users fine and allow them to create profiles , wire, messages all stuff. Just this avatar like facebook connect, gravatar brings in wordpress, Gigya is not able to do default way, however in gigya login widget it does show it. Just minor tweaks guess it will require and good to go.

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.

I am working on the same thing right now, has this been accomplished with 1.2 Beta? What is the correct process?

@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.

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.

The short answer is Yes. The long one is they are made for filling out forms and submitting them. A drop-down is just a field that they might encounter, so expect the functionality. On the other hand we are talking here about bots that look for WP/MU installations to exploit the default sign up or comment forms. As a rule of thumb, anything that you can do to change the default behavior, do it. It’s like Andy said: if you make it the default, the spammers will figure out a way to get around it.

Also: try very hard to stay away from the following in your URLs: wp-signup.php, wp-register, register, wpmu, wp, and anything that hints at a wordpress installation.

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.

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/