BuddyPress.org

You have two options:

1) Use a child theme to override the group header

Copy “/bp-themes/bp-default/groups/single/group-header.php” to your child theme’s directory keeping the directory structure intact.

Make your modifications there.

If you don’t know what a child theme is, read up here:

https://codex.buddypress.org/how-to-guides/building-a-buddypress-child-theme/

Stick with this method if you’re unfamiliar with WP’s actions and hooks.

2) Use BP hooks to add content to the group header

There are multiple hooks in the group header template that you could inject your content with.

The following two are probably what you’re after:

-bp_before_group_header_meta

-bp_group_header_meta

You could create your own functions and hook into these actions from your child theme’s functions.php.

If what I’m saying is completely foreign to you, read up on this:

https://codex.wordpress.org/Function_Reference/add_action

Installing and using BP has certainly become a lot easier since the 1.0 days, hopefully it will continue to get easier with each release.

There will be a 1.2 point release hopefully on the same day that 3.0 is released to fix any compatibility issues. 1.3 won’t be finished in time for 3.0. You can use the 1.2 branch to keep up to date with the fixes as they happen.

Ok, WordPress 3.0-beta is out. Just kidding. Well, I’m not kidding about it being out. I’m kidding about the compatibility being done.

I did wonder how the merge of WordPress and MU is going to affect BuddyPress though. Seems like it should be a great thing overall, but wasn’t sure if it would cause some short term challenges for BuddyPress.

Welcome to the BuddyPress community. No doubt not having to have WordPress MU is going to be a great thing for the BuddyPress community since it opens it up for a much larger community of users.

Lots of questions to address, so I’ll do it in the order they were posed.

@stwc

On the BP install I’m currently working on, the following long list of plugins (all of which seem to be working flawlessly activated non-sitewide) do not even offer the option for Site-wide Activation.

Is there a reason (or reasons) for that? Is there any possible downside? Or are they fine the way they are?

These plugins should work fine whether or not they are activated sitewide. However, there are two reasons why a BP plugin should be tagged to activate sidewide automatically:

1. Because they are BuddyPress-dependent plugins and require BuddyPress to work. Since Buddypress operates sitewide, then all add-on plugins are sitewide-acting by implicit reference.
2. By virtue of the first point, only Site Admins should have access to any plugin configuration. Offering all members with blogs access to these BP-dependent plugins in their admin dashboard only creates confusion as these plugins are for BuddyPress only and not for WordPress blogs.

______________

@hnla

So for clarity if one adds ‘Site Wide Only: true’ to pluginin files main description then it forces site wide activation regardless of whether one chooses to activate normally non site wide

This is correct. When the Site Wide Only tag is set to true, it does not matter which activation link is clicked as either action will result in sitewide activation. In fact, for all BP plugins I test, I simply click the “Activate” link right under the plugin name and not the “Activate Site Wide” link. If the plugin then shows under the Site Wide listing of plugins, I move on. If it does not, then I know that the plugin author failed to set the tag properly.

Edit/ found a plugin that already had ‘Site Wide Only: true’ set yet does not activate site wide using the plain activate link placing it self in the site wide section unlike bp-links. Is there something else that must be set to enable the site wide activation link or the ability to force the plugin to activate site wide?

Not that I am aware. It might be that the plugin has two Site Wide Only tags and there is a conflict. To which plugin do you refer?

______________

@MrMaz

Still unsure if I should add this tag to my plugin header. Shouldn’t it be up to the site admin to decide how the plugin is activated?

See my response in this post to @stwc. Since your plugin requires BP to operate, there is no value in letting non-admin members have access to your plugin via their blog dashboard. The more you can do to make installation, activation, and operation of your plugin foolproof the better. Is there actual functionality that your plugin offers if activated non-sitewide? What features of your plugin even make non-sitewide activation a desirable option to Site Admins?

______________

@hnla

In an ideal world I would like BP installed much as is but described differently but along with BP are installed a series of modules that can be activated or not by admin but that these are only activated from within BP so to speak always sitewide as BP is these modules representing some essential core set of features

I agree completely. I always refer to BuddyPress as a plugin suite but that never sat quite right with me. BuddyPress is a feature-rich platform as far as I’m concerned. It transcends the idea of a simple WordPress plugin. I also agree that many of the BP “plugins” are best described as modules as well. In fact, I consistently refer to my privacy “plugin” as the BuddyPress Privacy Component to separate it from the idea of it being just another plugin.

I could see the possibility of BuddyPress modules having their own set of 3rd-party plugins. So BuddyPress > 3rd-party BP modules > 3rd-party module plugins.

I also like your idea of requiring that all BP-dependent “plugins” get activated within a BuddyPress dashboard–instead of outside of BP. That could take care of all activation conflicts.

In my version of an “ideal BP world”, BuddyPress would become the foundation of the WordPress ecosystem as it is a user-centric platform and not blog centric. WordPress then would be a layer that sits on top of BuddyPress and could be activated if desired. So, Site Admins would install BuddyPress and then could check a box to install WordPress (in single or multisite mode), bbPress, and other modules.

Now I’m taking this thread too far of topic.

Look like that post was just a joke and trick to submit our emails to them…

Wp O Matic didnt update hes plugin for over 2 years but yet its best plugin wordpress have…

Hello to everyone following this thread. I just released version 0.4 of my Invite Anyone plugin, which, as promised, adds the invite-by-email feature.

https://wordpress.org/extend/plugins/invite-anyone/

Here’s what’s new:

– “Send Invites” tab added to the Profile section

– “Send Invites” has two subsections: Invite New Members and Sent Invites

– On Invite New Members, users can enter email addresses, a custom invitation message, and check off some groups that the invited member will receive invitations to when they join the site

– On Sent Invites, users can see all the invitations they have sent, as well as whether or not the member has accepted yet

– When a user accepts an invitation, they receive invitations to all groups to which inviter(s) have invited them, as well as a friendship request from each individual who sent an invitation

– A link is added to group Send Invites pages that goes to the profile Send Invites page and pre-checks the group’s box

– There’s a Dashboard panel for sitewide admins that allows them to control some of the default behavior of the Send Invites page, as well as the visibility of the Send Invites tab. You can create a blacklist of users who are not allowed to send email invitations (good if you have spammers in your community!), limit by blog role, or by length of time since joining the site.

It’s been fairly thoroughly tested, but it’s possible (likely even!) that there are still annoying bugs. Please let me know if you find issues or have suggestions.

They can still write *posts* to their activity stream. The word blog refers to the whole wordpress.com-like blog.

Not when someone logs in and writes an update. that is a post, not a blog.

For WordPress 3.0, the new tag to do this is:

Network: true

The only benefit is that you can let your users create fully featured wordpress blogs. If you do not need/want that, there is no benefit

@wordpresschina – see http://jeffsayre.com/2010/01/02/do-you-support-buddypress-privacy/

Ran into the same issue of 404 Not Found after activating BuddyPress on my WP installation on Ubuntu 9.10. Looks like the default Apache installation didn’t have mod_rewrite enabled.

To address this I did the following:

– sudo a3enmod rewrite

– sudo apache2ctl restart

– put .htaccess in my WordPress directory (/var/www) :

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

– put the following in /etc/apache2/apache2.conf

DocumentRoot /var/www

<Directory />

Options FollowSymLinks

AllowOverride all

</Directory>

<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews

AllowOverride FileInfo Options

Order allow,deny

allow from all

</Directory>

I haven’t tested to see if this is all needed or not, but that’s what my site has configured now and it appears to fix the issue.

I’m not aware of any precedent in plugins claiming to be BuddyPress compatible which aren’t

Mingle, a social networking WP plugin is one I’ve seen listed once a while in https://buddypress.org/extend/plugins/ when the plugin get’s updated. It doesn’t even claim to be BP compatible, it’s just tagged as buddypress.

I’ve just moved a localhost.localdomain install to a live server. It was easy as pie.

As I recall the steps: I moved the entire WPMU install to my live server, created an empty database. I exported my local database as SQL from PHPmyadmin, then opened up the export.sql file in Notepad++ and search-replaced all the URLs as necessary on the local file, then imported to the new, blank database.

I edited the wp-config file (and the bb-config as well) to update the db credentials and URLs, and almost everything just worked!

Once exception: I think I had to go into the Buddypress–>Forums setup and hit the button to setup the forums again for some reason, but after that, all was well.

The instructions here were helpful.

This would work moving between domains as well, of course.

Just posted this same error on wordpress but as i see they didnt give you solution for over a month… any ideas?

And wordpresschina, BuddyPress works on single WP installs right now.

not sure, but this can help you perhaps

http://maisonbisson.com/blog/post/14028/wordpress-hacks-managing-multiple-sub-domains/

or maybe, a simple hardcoded link on your main page to the bp register/login page, huh ?

@DJPaul: tks! weird… my search terms seemed to have been slightly off.

I installed the “Bulk Import Members (Users)” ( https://wordpress.org/extend/plugins/bulk-import-members-users/ ) but it triggered an install error:

Warning: require_once(bp-core.php) [function.require-once]: failed to open stream: No such file or directory in /var/www/my_site_name/wp-content/plugins/user-import-for-buddypress-all-fields/bp-user-import-adv.php on line 29

I searched more and found an alternative version of this (version 1.0.1) the the developer’s own site and it installs fine:

http://manojkumar.org/bulk-import-members-users-plugin-for-buddypress-site/

The other 2 seem fine too but not as comprehensive and new as the one above. I also have used dagondesign in the past and I like their plugins, but because it it not in the repository I fear about using these types of plugins sometimes.

It adds navigation links to blog ID #1 because… that’s how it works. Are you on WPMU, and /community is a sub-blog?

If so, you can change which blog BuddyPress runs on by using the following (e.g. blog ID 2) in your wp-config.php:

define ( 'BP_ROOT_BLOG', 2 );

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