BuddyPress.org

I just registered a test user so I could replicate the issue and I noticed this difference in the subject lines:

[Girls Can&#039 ;t WHAT?] Activate Your Account (intentional space left in to demonstrate the error)

[Girls Can’t WHAT?] New User Registration

The new user registration notice is correct in the subject line (the sender is still displaying wrong, although it used to just say ‘WordPress’ for the sender name.)

So is this a buddypress issue or a wordpress issue?

Perhaps ask them if they can help you further or if they can write a plugin to make it work with wordpress/buddypress?

@Anointed » Connections (the whole pack) works perfectly with groups in my installation (latest BuddyPress, latest SINGLE WordPress). Facestream gave me headache though.

https://wordpress.org/extend/plugins/post-layout/

In combination with..

http://firestats.cc/wiki/WPMUPluginCommander

Did you copy the buddypress default theme or did you copy a wordpress theme?

Activity/forums etc have their own template files.

I’ve been considering the same thing. In my research here’s the list of plugins I needed to still evaluate. Not a perfect plugin I think for this, but one of these plugins should be able to easily be modified to do what you want if you know a little PHP and WP/BP. Otherwise, I’m planning to dive into it myself over the next couple months. I hope these links help:

https://buddypress.org/forums/topic/join-all-public-groups-at-once

https://wordpress.org/extend/plugins/auto-join-groups/

http://buddypress.webdevstudios.com/blog/2009/11/13/buddypress-registration-options/

I also had the welcome pack on my list since it does make sense to have this part of it also.

We’re hiring freelancers. We’re also working in Miami this month if you want to live that whole code on the beach lifestyle. Long list of projects that need to be completed.

If you have experience connecting Buddypress with a CRM, managing publishing workflows, integrating with Drup*l, integrating with twitter/facebook/openid/oauth, custom MU code, custom content types, socket servers, and related items..

Contact.

https://buddypress.org/developers/nightlyfe/

I’d fill the small tasks list if there was one. Lets move on that asap!

Copy paste from an old post:

I propose that ma.tt create a premium service offering on wordpress.org. He should create a list of preferred service providers, pair them with module developers who need help, and let the community at large pay for support. all code is committed back to the plugin directly. Managed fixes and improvements, as well as a ‘certified’ list of ‘good’ plugins. Effectively, merge guru/elance/odesk with the popular list and an issue tracker.

Check out the Welcome Pack plugin: https://wordpress.org/extend/plugins/welcome-pack

It might be cleaner to use the current_user_can function to test. Check out the Roles info on the WP Codex, specifically the table (it makes it easy to see what roles apply):

https://codex.wordpress.org/Roles_and_Capabilities#Capability_vs._Role_Table

To make it a little cleaner you could do the following:

function my_alter_bp_sidebar_login () {

if( current_user_can( 'edit_posts' ) ) {

printf( '<a href="%s" title="Dashboard">Dashboard</a>',(get_bloginfo( 'wpurl' ).'/wp-admin/') );

}

}

This would show the link for any user who can “edit_posts” which is basically anyone other than Subscriber.

Jeff, you rule. I feel like I learned a lot about WordPress by reading your posts in this thread!

Okay, I’ve just gone through BP core and commented out all references to the plugins_loaded event accept for in bp-loader.php. I then refactored these references to hook into bp-init instead. All hooks worked fine accept bp-setup-nav. I had to set it to no priority or a priority lower than ten to make my navigation items show up in my plugin.

So, I outputted the various do_action arrays and discovered the issue. It is as I thought above–somewhat.

Not only does WordPress search for action calls top-down and alphabetically, it then reorders all action calls for a given hook by priority and if no priority is given, by the order in which it first came across a given action reference. Yes, I know, this is probably confusing most of you. Without seeing the output it may be too complex to visualize.

Here’s why my navigation menu was not showing up:

– All third-party plugins are now supposed to hook into the bp-init event

– The function in my plugin’s loader file that does that is called ‘BPAz_init’. It hooks into bp-init as follows:

add_action( 'bp_init', 'BPAz_init' );

– As you can see, I do not set a load priority on that action

– With the bp_setup_nav event (see line 2025 in bp-core.php) now tied to the bp-init event, instead of plugins_loaded, in my test core hack, and without setting any priority

add_action( 'bp_init', 'bp_setup_nav' );

it gets fired after my BPAz_init function and my plugin’s navigation menu appears

– But, if I set a priority below 10 for the bp_setup_nav event, my navigation fails to load. If I set a priority above 10, it loads. So,

add_action( 'bp_init', 'bp_setup_nav', 9 );

does not work, but,

add_action( 'bp_init', 'bp_setup_nav', 11);

works. My plugin’s navigation appears and functions.

So, the question is why?

Here’s the answer. It has to do with the fact that the function in my loader file that calls the bp-init event is found in a file that comes alphabetically before the file in which the function bp_setup_nav exists.

So, my function BPAz_init lives in a file found in /bp-authz/bp-authz-loader.php but function bp_setup_nav lives in /buddypress/bp-core.php. When the do_action function is processing the array, it sorts them first by priority and second by the order in which they were first loaded. Since my initialization function lives in a subdirectory that is searched before the buddypress subdirectory, my function that is hooked into the bp-init event is discovered before the bp_setup_nav action. This means that if no priorities are set for either function, things just happen to work fine by simple virtue of my plugin directory having a lower alphabetical order and thus higher search priority.

But if I set the priority for the bp_setup_nav action to be higher than ten (as in 9 or lower), then it is fired before my plugin is ever initialized and therefore my navigation menus cannot be rendered. If I set the priority for the bp_setup_nav action lower than ten (as in a number equal to or greater than 11), then my plugin is initialized before the bp_setup_nav event and my navigation menus work.

If I had not serendipitously named my file to something that has a higher alphabetical order than “buddypress”, I may never have discovered this issue. But, the moral of the story is this: the bp_setup_nav event must occur after all BP-dependent plugin’s have been initialized, otherwise their navigation menus will not appear. So, with the bp_setup_nav event tied to plugins_loaded, it fires before all BP-dependent plugin’s have been initialized. But, by setting a low-enough priority, it is possible to push that particular action of plugins_loaded to after all the BP-dependent plugin’s have been initialized. This is, of course, not the best way to do this.

As there may be other BP actions that are loaded too soon, I will need to spend a little time figuring out what this means for all the other action hooks in BuddyPress and BP-dependent plugins. The order in which an action fires can obviously be crucial. Since the firing order is based first on priority set, then on the alphabetical name of the functions that call a given hook, this can result in unexpected behavior.

Confused? Me too!

Buddypress on WordPress SU Really works for me!! I <3 Buddypress on WPSU!!!!

I’d recommend downloading BP 1.2.3 and doing a local search on the files, especially if you plan on doing any more customization – this will save you a lot of time.

That said, bp-core-templatetags.php probably has most of the functions related to this…

Here’s how I do it:

Print out the Username:

echo bp_get_loggedin_user_fullname()

There is also a related function that avoids the need to ‘echo’ that function. Search your bp files for this function and it’s immediately above or below that one.

Print out a URL to their Profile page:

echo bp_core_get_userlink( bp_loggedin_user_id() )

Although I think that gives you a hyperlinked userlink – if you review that function you should be able to figure out a way to output the raw url, if that’s what you are looking for.

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…