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.

In some countries you need to have a unsubscribe link, please consider Internet its not only USA.

We really have people using buddypress all arround the world.

And even in countries who is not forced by law, some of us like to have a good user experience and dont have some Sun of the B#$&#$& (read other bad webmasters or bad people) reporting you because you dont have a unsubscribe link, especialy when the email is send from your domain (wp default).

Please note I’m talking just in one feature, not talking on avanced send emailing who’s requires MTA configuration to respect isp limits, and so one… just a simple unsubcribe link

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.

MrMaz – which BP Version do you use for testing your development Version (DV)? I downloaded the DV and checked it on BP 1.2.3 and had some problems with an error message that won’t dissapear (Please fill in all of the required fields) and with fetching the page details.

Once my BuddyPress Privacy Component is out, Site Admin’s will easily be able to exclude their activity from the stream! And, since I know people will ask:

https://buddypress.org/forums/topic/privacy-component-where-is-it

I’ve posted some replies on the plugin on another thread: https://buddypress.org/forums/topic/invite-friends-from-profile

I’ll keep it here instead.

First test on single WP gives this error: Fatal error: Call to undefined function is_email_address_unsafe()…

@hnla – I’ve noticed this as well and sent an invite from another member’s profile but the email is sent from the member that is logged in. It just looks confusing as you can see the other member’s profile with the invites that you have sent.

Brajesh code for “Stealth Mode for Admins” also works for me BP 1.2.3/WPMU 2.9.2.

Just add to bp-custom.php

add_action("plugins_loaded","bpdev_init_sm_mode");

function bpdev_init_sm_mode(){

if(is_site_admin())

remove_action("wp_head","bp_core_record_activity");//id SM is on, remove the record activity hook

}

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

Yes sorry that’s my fault, yet I agree with your sentiments above re BP foundation and do think the nature, nomenclature and plugin/module approach is worthy of deliberation by the project team.

The plugin that caused me confusion was buddypress-classifieds which does have site-wide set to true yet doesn’t activate sitewide from ‘activate’ link only from the site wide link, suggesting it’s possible to circumvent the site-wide only: true.

I’d like to find out as it makes a lot more sense that ALL BP plugins simply activate site-wide and correspondingly automagically deactivate when BP not activated present. less to go wrong then.

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.

Slightly tangental – apologies. This discussion brings to my mind the fact that in many ways I find the description of Buddypress, Buddypress-links, BP-Events, BP-Album and others of the same ilk as far more than plugins; plugins tend to make me think of things that are fun but not essential in any way to the operation of the core application whereas Buddypress whilst not necessary to WP is not simply a plugin it changes the working nature of WP and is far more suited to being known as a module or something to set it apart.

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 e.g Links, Events, Album etc. In some ways that would also remove any confusion as to how they were activated, but I also realise that single WP probably has to be considered somewhere in all that.

The issue is that whatever theme you are working with has a style.css that applies rulesets using descendant selectors and on the elements you mention your style.css describes generic styles for things like ul li elements but as child elements of parent such as #content.

The stylesheet that appears to be created to apply the necessary styles required by buddypress i.e bp.css is styling on the class tokens.

As an example the div.item-list-tabs ul element requires and has a margin:0 applied in bp.css however in styles.css you have #content-body ul applying large margins and this ruleset has a higher specificity or weight due to the use of the ID selector which will override the clas selector described in bp.css.

I’m afraid that you have a little work to do to in getting whatever theme it is to work for BP, perhaps the fastest approach is open up bp.css and where you have :

div.item-list-tabs ul {}

Add to the beginning of the selector statement #content-body

#content-body div.item-list-tabs ul {}

This would enusure that the BP rules carry a higher weight and will win out or overrule.

Not sure if the OP actually expressed a dislike for Gravatar especially , but the overall issue is an interesting one. Over the last few years with the rise of offsite script calls and general offsite info being called into pages there are noticeable times when page loading stalls. It’s not a BuddyPress issue per se.

easy for anyone to to tagged their plugin ‘buddypress’ maybe there needs to be a verification? (in the code?)

@david Thank you so very much!!! I´ve been trying for a long, long time to create dropdown-menus for buddypress default theme, with no luck. Your solution works for me too.

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

Thanks Jeff, that’s an incredibly useful bit of info. I had wondered about when site wide should be used as was never too sure, but had noticed that certain plugins activated NON site wide would place themselves in the top section of activated plugins as site wide only, now I understand how this happens.

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. tested this with buddypress-links and is as described.

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?

@Jeff Sayre: Please make sure to have a donation button created for this plugin, as I will gladly put down some cash to you each time I can get a client do use buddypress for their projects. This privacy/security component is **very** important part that has previously been missing from BP….

http://www.searchhyip.com/ -check header…

Check it out and link to my other site where is total mess i cant provide, i eman i can but buddypress is not installed since it mess whole site and i have many visitors online.

But here it is if you wish to see what this theme have http://www.todump.com

Those users must become active to show up in member listings. If they log in to the site at least once they will show.