BuddyPress.org

Also posted here: https://wordpress.org/support/topic/multisite-vs-buddypress-strategy?replies=3 where folks had some answers

MultiSite = Multiple blogs/sites
BuddyPress doesn’t require multisite and it’s not a vs strategy, and more of a ‘What are your needs”

BP plugins can certainly do what you want, but so can a custom post types, or separate sites on a Network.

@mercime Registration works normally in WordPress, as well as on a clean staging site with all the same plugins.

Same here! I’d love to be able to use the great functionality of WordPress Users along with Buddypress and am quite surprised that I’m not seeing how to do this yet. I’d like to hear from others.

Are you on BP 1.2.8? I think we may have fixed this in trunk, it rings a bell. Best to report it on https://buddypress.trac.wordpress.org/ please so we can check it out. Let us know version numbers of WP/BP that you are using at the moment.

I would also love something like this, I just posted something similar in a different area. Not sure how I missed this thread. It is a bit disappointing that the great user management features of WordPress don’t work with BuddyPress.

Try this new plugin by BP’s very own Boone Gorges – “Unconfirmed”:
http://teleogistic.net/2011/05/new-wordpress-plugin-unconfirmed/

(Edit) Are you talking about manually activating user accounts on your BP install? Or are you talking about members not showing up in the members directory?

i am using bp role manager to create roles for users in wordpress.
now i want to that only user with specific role should be approved by admin through BuddyPress Registration Options plugin it is now used for every type of users registered.
how can i do this plz suggest.

Your language files are currently suffixed with “WyoDLC”. Try using “en_US” or whatever your WordPress locale is.

If you want to keep your language files with the suffix “WyoDLC”, use this snippet in /wp-content/plugins/bp-custom.php:
`define( ‘BPLANG’, ‘WyoDLC’ );
if ( file_exists( WP_LANG_DIR . ‘/buddypress-‘ . BPLANG . ‘.mo’ ) ) {
load_textdomain( ‘buddypress’, WP_LANG_DIR . ‘/buddypress-‘ . BPLANG . ‘.mo’ );
}
`

Also make sure to rename your languages directory back to /wp-content/languages/.

If this still doesn’t work, try regenerating your .po and .mo or post about the “weirdness” you’re experiencing.

Even the bbPress plugin comes with a small set of fallback template files (as a child theme of twentyten) to display forums.

I didn’t say we’d get rid of bp-default! bp-default can continue to be a parent theme. Even if we backport the simplest changes from bbPress for now like get_template_part() to BP (instead of locate_template() like Bowe mentions above), this will make things very easy to build a plugin to serve BP template files without copying them over to the WP theme (as BP Template Pack does now).

In my unreleased plugin, I created a function similar to bbp_get_template_part(), copied bp-default BP-only template files to my plugin directory and swapped out locate_template() for this new function. The plugin served BP template files. Then, combined with this, all you’d need to is create a header-buddypress.php (or footer-buddypress.php, etc.) in your WP theme to make it gel with BuddyPress.

@jml1618 just to clarify, is your WP installed like this https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory (because this set up won’t work with BP) or is your WP/BP installed in a normal subdirectory?

https://wordpress.org/extend/plugins/buddypress-restrict-group-creation/
– Note that the plugin will not be updated for future versions of BuddyPress (like 1.3+) by current plugin author. Hopefully, someone will take over the plugin.

Or, check this out http://bp-tricks.com/coding/manage-group-creation-by-creating-a-group-request-form/

re: default-home, default-member, bphome, bpmember, bp-sn-parent, and bp-default themes
Thank you.

re: get_template vs locate_template
A great article on proper usage of get_template_part and locate_template can be found here: http://justintadlock.com/archives/2010/11/17/how-to-load-files-within-wordpress-themes.
locate_template – function searches in the STYLESHEETPATH before TEMPLATEPATH so that themes which inherit from a parent theme can just overload one file https://codex.wordpress.org/Function_Reference/locate_template.

They way JJJ describes it would be the way to go imo.. Looking at the BBPress beta this seems to work well, and it would make things a lot easier (and more fun). I have another question about templating though;

1: Using get_template instead of locate template Is there a reason why locate template is used in BP-Default instead of get_template? Looking at TwentyTen and TwentyEleven they all handle it with get_template.. From what I understand from talking to MrMaz it also allows greater flexibility doing it like this. Because get_template can be filtered/hooked into while locate_template is very inflexible.

2: <get_template_part: This seems to be the way forward for new themes. It allows you to load specific template parts in your theme so you can reuse them. (https://codex.wordpress.org/Function_Reference/get_template_part)

I think both of these things could make the theme more flexible and easier to work with.

Hi @All,

I’m writing for themekraft.com, we are a young startup, making our lives with WordPress and 80% BuddyPress related development.
Buddypress has changed our lives and we want to count us in.
We have read the thread from bowe at bp-tricks.com and this thread here, and we want to help, too. It’s like bowe and this thread is bringing our thoughts to the public, and we feel it’s time to come together.

We are 3 people, and we can give 2 hour every week to help out. That makes 6 hours – let’s say one day a week.
We are two developers and 1 theme designer.
There are many small and bigger problems we found in our daily work, we like to have changed. And we would immediately start helping.

For example: bp-default:

We have developed a theme for BuddyPress. And in the theme you can change sidebars, also for BuddyPress components .
But it’s very difficult for us to provide a left sidebar only, because buddypress comes with a right sidebar in the default theme and the sidebar is included in the pages instead of in the header and the footer.

Every component that extends BuddyPress, comes up with the right sidebar in the template files.

That means for us (and all theme devs with theme options like sidebars), we have to rework every template file from every plugin to support having just a left sidebar.

This is just one theme example, we would like to share all experiences to improve theme development with BuddyPress.
We know, there must be at least some templates files for buddypress to work. But they should integrate in different way as now.
We have read this thread, and there are quite a lot of people willing to get their hands on the bp-default.

Wouldn’t it be a great thing to have the bp-default in github, so we can create a team to work together the git way?
There is also an issue tracker in github, and I feel it’s much easier as the trac…

This way integration in a new bp-default team would be very easy.

Patches and all the BuddyPress stuff.

We have done some funny things with custom post types and groups, because it is so difficult to filter groups in a certain way.
Also if we use the custom post type api, we get a lot of benefits like revision backups and so on.

To be honest, we believe that BuddyPress could handle groups more powerful, and we would like to work on this, too.

I have seen the conversation from the BuddyPress ninjas in the early days of 1.2 where JJJ started to think of groups in a API way.
Everything is a group. Like a group of people and so on. I really liked the idea and we would like to see groups become something more powerful.

I will stop writing now, hoping we will just start working, as I guess everything has been discussed before.

Thanks for all, we love BuddyPress and see it us a powerful tool to build great websites, often without the need of a direct social network, using it to realize our customers needs.

We look forward to start helping. We always had the feeling before, that it’s not so easy to become a working part.
So just let us know where we can start, or what you need to be done

Thanks,
svenl77, konradS and mahype

Thanks for posting about this problem.

This is fixed in the upcoming release of BP, though not for v1.2:
https://buddypress.trac.wordpress.org/ticket/3189

If you encounter any other bugs, please post them on BuddyPress Trac:
https://buddypress.trac.wordpress.org/newticket

Login with the same credentials you use on buddypress.org.

If it is a WordPress post or page, check out this function:
https://codex.wordpress.org/Function_Reference/is_page

If it is a BuddyPress page, then you’ll need to use `bp_is_blog_page()` to check to see if you’re on a BuddyPress page.

In the meantime, as of BP 1.3 trunk-4414

1. open up https://buddypress.trac.wordpress.org/browser/trunk/bp-themes/bp-default/functions.php

2. comment out line # 163 and lines #170 to #175

3. add to your child theme’s stylesheet
`@ import url( ../../plugins/buddypress/bp-themes/bp-default/_inc/css/reset.css );
@ import url( ../../plugins/buddypress/bp-themes/bp-default/_inc/css/default.css );
@ import url( ../../plugins/buddypress/bp-themes/bp-default/_inc/css/adminbar.css );`
delete space between `@` and `import`

It’s nothing you can fix from the admin of WordPress, as it’s completely server side.

Are you on a Winders server?
Can you ask your host about removing index.php from the permalinks?

It’s not a hack just sounds like you haven’t added ‘buddypress’ into the list of tags in the style.css head meta? without buddypress in that tag list the warning is displayed.