BuddyPress.org

Hi
in short everything you have asked can be done.

But I’m a little bias as I honestly believe regarding technology there is nothing that can’t be achieved it just comes down to how much time and budget you have to invest… 🙂

Below is a bit of a ramble…. But might provide insight. after you organize your coffee and come back.

I have nearly completed a project that sounds similar in nature (few weeks from launch in final beta testing), however it was a highly customised solution (private membership site) .
With nearly 70 plugins, 100’s hours coding integration code (lots of trial and error) between the plugins and also compatibility tests with multiples of plugins to ensure no issues, because of slow load times the project requires deploying from CDN,fast servers and customised caching solutions.
most of work load appeasr to be bbpress – so an near out of the box solution, you prob don’t need to go that far.

But not to scare you. Here are some pointers that might answer your questions, based on my understanding of the OP.

In my case I spent many months researching solutions with many platforms (open source / paid / managed premium) – buddy press was selected simply because is built on WordPress that’s already has the core abilities you need, you just need to “hook in to’em” and take advantage of this concept – you can keep working on bettering and adding separate components / features as time goes by, great for client, works out a bit cheaper in the startup phase and great for developer – land ya self a permanent support / ongoing development contract……

Is it possible to update profile content/meta? : In general yes, buddy press allows this out of the box

Either the user or the admin can update, you can have admin only fields (the user doesn’t access them – but the admin can)
if you use a membership plugin eg, s2member – you can extend this idea much further eg, only require email on signup, then all other fields are accessible from profile and can set fields on a per membership level,

In your case, you might have different profile fields for students, teachers, Parents and only require a couple of basic fields to be completed on signup and all other fields can still be “required” when they reach their profile page.
For profile field management I recommend the s2membership pro plugin (free version available) http://s2member.com/

My project has a “todo list” for each and every member – however I’m still to this day unable to find a plugin that interacts with a completed wp/bbp/buddypress site. So I had to code one. The todo list was designed / engineered in a way that interacts with “wordpress” in general, by storing a completely unique data feed much like the activity feed with time stamps and can be programmed to be linked to any site link, media download, page view, forum post, reply any activity on the site can be logged and applied to the feed which the to-do-list interacts with and auto completing (crossing of the item) each item also has dependencies, so you rattle off a list of activities before the task is crossed off and each to-do-list also has dependencies so it is not seen by a user until certain tasks are completed, eg, purchase a course from the store, or complete a previous to-do-list.

In short: Yes it can be done, however I’m not aware of any 3rd party plugin that does this successfully.

In my case I have the to-do-list shown in the sidebar so as a member goes through the tasks the list is also available to them no matter what page they are on. But possible to publish it in the profile page if required.

Regarding email notices, I recommend looking into the woo commerce sensei http://www.woothemes.com/products/sensei/ plugin for your courses that way you have management of email notices, in fact prob most of the things you require will be available via sensei – note this is a premium paid plugin with yearly ongoing licence costs.
Without a free trial version to try before you buy.

But maybe gravity forms developer licence might be fine in your case as it has, gateway plugins, qiz and survey plugins – it would be possible to build certain simple courses on the gravity framework including delivery of custom emails – if building a form based system than certainly worth a look into – but would require a developers licence to get all the plugins you would prob require.

In fact what I do is use gravity forms email chimp plugin to send the members email address to an email list (automation campaign) in mail chimp (paid account) that auto sends a welcome emails that I have customize to suit the activity they have completed, this way I can send pretty html + marketing emails + scheduled follow up emails and take the work load off WordPress other than a quick API connect on demand.

Regarding: is it possible to have multiple logins or users access the same account/profile?
In simple: Yes, but it all comes to context of the profile, will each member be able to see other members profiles or will parents be able to edit a child profile etc.

Although my project does not require the need for 2 or more members to edit a single profile, I do have multiple levels of context (horizontal and vertical memberships) all with their own set of rules who profiles they can see and what buddypress features are available to them – some members don’t have activity feeds or messages, But I needed to ensure that members that do have access to these features can’t access the features of cross membership and so on.

This is 100% custom code (no plugin) but while coding this up I recall thinking I’m 100% confident it is possible to add another level of check “if current user can edit displayed user” and go from there, all you would need is a profile field / meta that links multiple accounts together –
Eg, a parent account has a profiled field “child user name” – they just enter the child username / user ID – and now we would add the profile check if a parent is viewing the child’s profile.

Regarding paying a deposit, and payment, this is my findings.

There was no single one membership / payment plugin that integrated perfectly into what I wished to achieve – I have tested many. please note I’m suggesting there are no plugins that do this stuff just none that achieved the outcomes I needed for my project.

– Tips: – start the project design based on the payment systems / gateway (the complete project and direction of development is 100% dependent on this) because the simple reason every feature you implement needs to check “is a paid member and what level (cap / role) ” – including free membership with paid features “is not a paid member” but has paid for… this includes recurring and non-recurring subscriptions with consideration of what you intend to do if a subscription expires.

Eg, a recurring subscription will either just auto subscribe and pay for the next time frame (or fail)
A non-reoccurring subscription will auto expire after a given time frame (or X cycles)

The difference between to the two –
Is generally on a recurring subscription when it expires it also linked to a member account to “do something” eg downgrade membership

A non-recurring subscription is generally used for a onetime payment you have access forever feature- eg, a course and resources, you pay once on a deposit, subscription over several weeks when the subscription expires the member still has access to the course as long as they remain at minimum a free member on the site. (anyhow that’s how I have implemented things)

These two concepts are completely different in the way they interact with the member as well at many levels although on the surface appear to be almost the same, add in a deposit feature you are also opening another level of context to play with, mostly limiting the available options regarding the payment gateway service you will need to use or more so which services have this feature on offer.

As mentioned – my suggestion is start with the gateway solutions first and reverse the design back to the front end. – this is the big lesson I took away with this project (4 rewrites in total) as it was always a block relating to the gateway limitations (and laws relating to online subscriptions in my country).

My project:
Woo commerce (free) for shopping cart system including purchase of courses, subscription to site and deposit/ subscription to courses, plus all other products, deliverable products, workshops, webinars, one on one sessions, resource downloads from pdf to videos. Anything you can think off can be sold through woo

Woo commerce quick cart – plugin (paid)– now I can add a buy now button on any page for any product including subscriptions – the membership info page has a standard 3 column price comparison chart with nothing more than a “sign up now” button – clicking the button auto adds the subscription to cart and opens the checkout popup with one click and without leaving the page (no need to send to store)

Sensei (paid)– for courses and fits well into woo commerce system (but requires a couple more plugins and custom integration code if implementing paid / subscription based courses )

Groups plugin (free) to easily manage roles and caps (as I have to teach client staff how to do this and manage the site) WordPress has this capability built in if your a coding ninja (I’m not)

Groups Woo commerce (paid plugin) to link groups to a purchase – apply a role / cap or groups of, to a user based on the purchase.

Then some custom code is required – to perform a check and if a user has a particular role or cap than apply the s2membership level – this check is done at the store level so if a member cancels or defaults on a payment – the membership level is auto adjusted depending on what role or cap is supplied to the user from the groups woo commerce automation. groups plugin manages non-recurring subscriptions so a expired subscription does not remove the users caps and roles (but a default on payment does)

S2member pro – for membership level management including profile fields management and most importantly complete site access management – I can apply access to each and every competent of the site this includes , forums, topics, replies, posts, pages, media, courses, and content within pages eg, home page displays different content based on the membership level / logged in or general public. s2member pro is also used to override default bbpress / buddy visibility settings eg, hidden forums only available to certain member levels – but requires custom code to apply or traverse access levels on submitting topics / replies to ensure widgets and other snippets don’t display private areas to members that don’t have access. (it allows you to write custom queries with zero concern or consideration to access levels)

For subscriptions (paid)– I use woo commerce Subscriptions plugin – this manages on its own site access based on paid recurring subscriptions (or in simple turns on or off user account based on payment) – pay x amount monthly to access certain site features, courses and resources, forums, pages, blog articles etc.

However – woo commerce subscriptions does not manage deposit / time based subscriptions (non-recurring subscriptions) eg, pay a deposit for a course and gain instant access then pay off on a subscription for x amount of weeks / months –
I was not able to find any plugin (free or paid) that does this, so I had to write a plugin currently under experimental concept stage.

Other tips: often it’s better to find compatible, well supported and pay for premium plugins that have overlapping features and disengage these features you don’t want to achieve your goals and do as little integration code as possible, but anything you do needs to be well planned and though out as to not to touch core code in any platform, framework or plugin.
At the end of the day you want the ability to upgrade all systems as time go by.

Eg, s2member plugin has its build in membership system that is “required to be active” for the plugin to work. – all I did was setup a single paid (never to be used membership) on a paypal sandbox store this includes setting up all the s2membership registration pages etc – then put a simple redirect in the .htaccess on any of these pages. Now to purchase membership you must go to the store (woo commerce) and purchase a subscription via woo – s2member has now has nothing to do with membership registration / payment systems.

And of course I have “force account creation” turned on at the store – you cannot make a purchase without signup at a minimum free site membership.
by disengaging the buddy, bbp, Wp, and all other means of registering (by redirect) but only leaving the woo commerce customer account registration available – The pop up registration form I use for free members is just a woocommerce customer account registration form (with no products attached) with a fallback to the s2membership cut down reg form (in case ajax / jquery etc not working on client side)

And now all purchases, subscriptions, shop account, courses etc are now available from the buddy press profile page also via a “woo to buddypress” plugin (or in my case built into the theme)

May sound complicated but as mentioned I would really suggest starting with payment solutions and nut out this part of the project first as this will most likely force development direction,

one of my project goals was a solution that can cater for anything…. so,

Regarding variable deposit / costs amounts based on user input – if using similar approach as I did – you would just setup woo commerce discount codes per variable outcome / result and would just reveal the correct coupon code to the user on the checkout page. they just cut and paste this code into the discount field and click apply.

or setup up multi products – one product per price base. – have the user input their details first and the result would be – apply a groups cap / role then only offer the courses products in the store with the associated price base based on user caps / role –

woo discount coupons can be setup on multiple bases – eg, deposit amount / on going subscription amount or total amount or per product or per cart total etc.

for me was plenty of research into this including concept builds of other community platforms and as above is only a bit of a sample of features used relating to the OP.
I was under very strict key point goals and achievements requiring very specific outcomes many of these affected development direction how / why I implemented the above.

There may be better simpler ways to suit your specific project, but thought it might be worth a mention for some direction. or at least insight into some of the plugins I use / ideas and concepts.

my usual disclaimer – if there is something in there for you, that’s great! if not that’s fine too!

enjoy!

Untested, but try:

function jake_nav_remove($nav_array) { 
	
    if( ! bp_is_my_profile() ) {

         $roles = wp_get_current_user()->roles;

         if (in_array('Supporter', $roles)) 
             $nav_array = '';
    }

    return $nav_array;
}
add_filter('bp_get_displayed_user_nav_activity', 'jake_nav_remove', 10, 1 );
add_filter('bp_get_displayed_user_nav_profile', 'jake_nav_remove', 10, 1 );

However – removing these tabs can create problems – ‘profile’ is the default tab ( and therefore screen ) for member pages. You’ll need to decide on which tab should be default, since you may remove profile and activity.

Please read here to show WP’s user roles:

https://buddypress.org/support/topic/displaying-user-roles-in-profile/

Musician and venue are not roles, but member types which is a different thing. For that read here:
https://buddypress.org/support/search/display+user+role+on+profile+page/

Yes indeed, there is a way.

Step by step tutorial with example code which you add to bp-custom.
Note: use this code as is and follow the instruction. Once you understood what it does and how it works, you will be able to modify it to your needs.

First, create a new xprofile field in the first group field (aka Base Group and containing Name as default field). Only fields created in that group are visible on the register page. Call it Type, enter description and choose multiselectbox as field type. Add operator, vendor, coach as select option.

That’s all for the register part handled by BuddyPress.

Now we need to declare the whole thing to get it work on front-end.
Member-type is an additionnal functiony to select members by… type ! Not by role, not by latest, mst popular or anything else. Just (for the moment) by a custom type of your choice.

We have to built a member directory for our types. We have 3 types and they will be shown on 3 new tabs on that directory.

1) we formally declare the member types
2) we count members by type (to stay correctly informative on the directory)
3) we display the tabs

function using_mt_register_member_types() {
	bp_register_member_type( 'operator', array(
		'labels' => array(
			'name'          => __( 'Operators', 'using-mt' ),
			'singular_name' => __( 'Operator', 'using-mt' ),
		),
	) );

	bp_register_member_type( 'vendor', array(
		'labels' => array(
			'name'          => __( 'Vendors', 'using-mt' ),
			'singular_name' => __( 'Vendor', 'using-mt' ),
		),
	) );

	bp_register_member_type( 'coach', array(
		'labels' => array(
			'name'          => __( 'Coaches', 'using-mt' ),
			'singular_name' => __( 'Coach', 'using-mt' ),
		),
	) );
}
add_action( 'bp_init', 'using_mt_register_member_types' );

function using_mt_count_member_types( $member_type = '', $taxonomy = 'bp_member_type' ) {
	global $wpdb;
	$member_types = bp_get_member_types();

	if ( empty( $member_type ) || empty( $member_types[ $member_type ] ) ) {
		return false;
	}

	$count_types = wp_cache_get( 'using_mt_count_member_types', 'using_mt_bp_member_type' );

	if ( ! $count_types ) {
		if ( ! bp_is_root_blog() ) {
			switch_to_blog( bp_get_root_blog_id() );
		}

		$sql = array(
			'select' => "SELECT t.slug, tt.count FROM {$wpdb->term_taxonomy} tt LEFT JOIN {$wpdb->terms} t",
			'on'     => 'ON tt.term_id = t.term_id',
			'where'  => $wpdb->prepare( 'WHERE tt.taxonomy = %s', $taxonomy ),
		);

		$count_types = $wpdb->get_results( join( ' ', $sql ) );
		wp_cache_set( 'using_mt_count_member_types', $count_types, 'using_mt_bp_member_type' );

		restore_current_blog();
	}

	$type_count = wp_filter_object_list( $count_types, array( 'slug' => $member_type ), 'and', 'count' );
	$type_count = array_values( $type_count );

	if ( empty( $type_count ) ) {
		return 0;
	}

	return (int) $type_count[0];
}

function using_mt_display_directory_tabs() {
	$member_types = bp_get_member_types( array(), 'objects' );

	// Loop in member types to build the tabs
	foreach ( $member_types as $member_type ) : ?>

	<li id="members-<?php echo esc_attr( $member_type->name ) ;?>">
		<a href="<?php bp_members_directory_permalink(); ?>"><?php printf( '%s <span>%d</span>', $member_type->labels['name'], using_mt_count_member_types( $member_type->name ) ); ?></a>
	</li>

	<?php endforeach;
}
add_action( 'bp_members_directory_member_types', 'using_mt_display_directory_tabs' );

We also need to sort the members list on each type tab using the loop scope.

function using_mt_set_has_members_type_arg( $args = array() ) {
	// Get member types to check scope
	$member_types = bp_get_member_types();

	// Set the member type arg if scope match one of the registered member type
	if ( ! empty( $args['scope'] ) && ! empty( $member_types[ $args['scope'] ] ) ) {
		$args['member_type'] = $args['scope'];
	}

	return $args;
}
add_filter( 'bp_before_has_members_parse_args', 'using_mt_set_has_members_type_arg', 10, 1 );

And we finally clean the cache to stay up to date with the output

function using_mt_clean_count_cache( $term = 0, $taxonomy = null ) {
	if ( empty( $term ) || empty( $taxonomy->name ) || 'bp_member_type' != $taxonomy->name )  {
		return;
	}

	wp_cache_delete( 'using_mt_count_member_types', 'using_mt_bp_member_type' );
}
add_action( 'edited_term_taxonomy', 'using_mt_clean_count_cache', 10, 2 );

That’s all for a members directory page showing All Members and tabed Members by type.

If you want to show the type of a member on his profile header, use this:

function using_mt_member_header_display() {
	$member_type = bp_get_member_type( bp_displayed_user_id() );

	if ( empty( $member_type ) ) {
		return;
	}

	$member_type_object = bp_get_member_type_object( $member_type );
	?>
	<p class="member_type"><?php echo esc_html( $member_type_object->labels['singular_name'] ); ?></p>

	<?php
}
add_action( 'bp_before_member_header_meta', 'using_mt_member_header_display' );

Or if you want to display the type under each user avatar on the member directory, you can use this snippet. Note: was originally made to add a geoloc shortcode below the member type. I let it as is, so you can see how it’s done.

function who_are_you_directory() { // by member_type name + geoloc (wpgeo me)
$user = bp_get_member_user_id();
$terms = bp_get_object_terms( $user,  'bp_member_type' );

	if ( ! empty( $terms ) ) {
		if ( ! is_wp_error( $terms ) ) {		
				foreach( $terms as $term ) {
					echo '<p>' . $term->name . '</p>'; 					
					echo do_shortcode('[gmw_member_info]');
				}		
		}
	} 

}
add_filter ( 'bp_directory_members_item', 'who_are_you_directory' );

Anything inspired by Codex and heavy topics reading.

Member Types

Members Loop

May this help.

Interesting discussion 🙂

First i’ll explain why i’m using bp_is_active( 'activity' ) : it’s just an extra check to be absolutely sure the activity component is active. I do it because BuddyPress is a set of components you can activate / deactivate from the BuddyPress settings. So if the activity component is not active, no need to add Post Type activities. And when you develop a BuddyPress plugin, you need to remember there can be configs that deactivated the component you are extending.

Second, about the contexts argument. In this codex page https://codex.buddypress.org/plugindev/post-types-activities/ i’m describing a bit his role
Here https://codex.buddypress.org/themes/activity-dropdown-filters-in-templates/ i’m talking about the way we are getting the activity types since BuddyPress 2.1 And finally reading this page https://codex.buddypress.org/developer/function-examples/bp_activity_set_action/ you will see the interest of the contexts argument.
In short the contexts argument is a way to control where you want an option (activity action) to be displayed. For instance if you want to include an option into the single group’s home page dropdown filter you do contexts => array( 'group' )

In the case of a post type, i think in most cases there’s not a great interest to have the activity filter in the group’s single home page because in most cases the post type have been created out of a BuddyPress group (mainly in WP Admin actually). That’s why in my example i suggest to use 'contexts' => array( 'activity', 'member' ), ‘activity’ means display the dropdown option into the activity directory and ‘member’ display it into the member’s profile. The ‘member’ context is interesting in the case of Post Types activities because a post type is always created by a user_id.

Now with the question “could it be possible to display Post type activities into a given group’s stream ?” we must understand this part 'component_id' => 'activity' Here you are defining the component you want the Post type activities to be linked to. So you could say cool! lets put ‘groups’ to have activities in groups. But here you’d be wrong because all generated activities would be displayed in the first group the one having the id #1 (If multisite it could give another illusion…) Why id #1, because it’s the id of the blog where was created the post type. So you would need to have a different value depending from which group the post type was posted. As in core we don’t include a feature to post a post type from a group, by default we are setting the item_id field to the current blog.

Unless you want to arbitrary display the activity in one particular group, i’d say this need should only concern Plugins extending the Groups component. Of course it’s possible, and i’ve done it for one of my plugin.

I hope my explanations will help you @youmin.

Hi @screampuff

You could try the following function which will stop unwanted users from viewing the page directly if they tried typing the URL:

function my_hide_achievements_page() {
    $role = xprofile_get_field_data( 'Membership' );

    if ( ( $role != 'Administrator' ) || ( bp_current_user_id() == bp_displayed_user_id() ) )
        return;

    // I guess we should 404 this page because this member isn't an admin or the displayed member.
    $wp_query->set_404();
    status_header( 404 );
    nocache_headers();
}
add_action( 'init', 'my_hide_achievements_page' );

<?php

/**
* BuddyPress – Users Home
*
* @package BuddyPress
* @subpackage bp-default
*/

//get theme options
global $oswc_bp;

//set theme options
$oswc_bp_sidebar_unique = $oswc_bp[‘bp_sidebar_unique’];
$oswc_bp_members_sidebar_unique = $oswc_bp[‘bp_members_sidebar_unique’];

//setup variables
$sidebar=”Default Sidebar”;
if($oswc_bp_sidebar_unique) { $sidebar=”BuddyPress Default Sidebar”; }
if($oswc_bp_members_sidebar_unique) { $sidebar=”BuddyPress Members Sidebar”; }

get_header( ‘buddypress’ ); ?>

<div class=”main-content-left”>

<div class=”page-content” id=”content”>

<?php do_action( ‘bp_before_member_home_content’ ); ?>

<div id=”item-header” role=”complementary”>

<?php locate_template( array( ‘members/single/member-header.php’ ), true ); ?>

</div><!– #item-header –>

<div id=”item-nav”>
<div class=”item-list-tabs no-ajax” id=”object-nav” role=”navigation”>

    <?php bp_get_displayed_user_nav(); ?>

    <?php do_action( ‘bp_member_options_nav’ ); ?>

</div>
</div><!– #item-nav –>

<div id=”item-body”>

<?php do_action( ‘bp_before_member_body’ );

if ( bp_is_user_activity() || !bp_current_component() ) :
locate_template( array( ‘members/single/activity.php’ ), true );

elseif ( bp_is_user_blogs() ) :
locate_template( array( ‘members/single/blogs.php’ ), true );

elseif ( bp_is_user_friends() ) :
locate_template( array( ‘members/single/friends.php’ ), true );

elseif ( bp_is_user_groups() ) :
locate_template( array( ‘members/single/groups.php’ ), true );

elseif ( bp_is_user_messages() ) :
locate_template( array( ‘members/single/messages.php’ ), true );

elseif ( bp_is_user_profile() ) :
locate_template( array( ‘members/single/profile.php’ ), true );

elseif ( bp_is_user_forums() ) :
locate_template( array( ‘members/single/forums.php’ ), true );

elseif ( bp_is_user_settings() ) :
locate_template( array( ‘members/single/settings.php’ ), true );

elseif ( bp_is_user_notifications() ) :
locate_template( array( ‘members/single/notifications.php’ ), true );
// If nothing sticks, load a generic template
else :
locate_template( array( ‘members/single/plugins.php’ ), true );

endif;

do_action( ‘bp_after_member_body’ ); ?>

</div><!– #item-body –>

<?php do_action( ‘bp_after_member_home_content’ ); ?>

</div>

</div>

<div class=”sidebar”>

<?php if ( function_exists(‘dynamic_sidebar’) && dynamic_sidebar($sidebar) ) : else : ?>

<div class=”widget-wrapper”>

<div class=”widget”>

<div class=”section-wrapper”><div class=”section”>

<?php _e(‘ Made Magazine ‘, ‘made’ ); ?>

</div></div>

<div class=”textwidget”>

<p><?php _e( ‘This is a widget panel. To remove this text, login to your WordPress admin panel and go to Appearance >> Widgets, and drag & drop a widget into the corresponding widget panel.’, ‘made’ ); ?></p>

</div>

</div>
thats what I did:
</div>

<?php endif; ?>

</div>

<br class=”clearer” />

<?php get_footer( ‘buddypress’ ); ?>

Yes, there should be a way, but I was not able to follow the instructions / to realise that way.

The basic idea is:

• Create two (or more) new WordPress user roles, e.g.: Users-UK and Users-USA.
• Then you can assign one xProfile-field, ‘In which [federal] state do you live?’, exclusively to your users with the user role Users-USA; and another x-Profile, ‘In which county do you live?’, to your users with the user role Users-UK.

—

The instructions for that solution you find there:

https://buddypress.org/support/topic/resolved-different-profile-types-and-different-user-roles/

(The user roles there are ‘bands’ and ‘fans’).

And my report about my attempt to apply that instructions you find there:

https://buddypress.org/support/topic/different-profile-types-and-different-user-roles-part-ii/

My user roles are (sport) ‘teams’ and ‘fans’.

—

But unfortunately, I was not able to hinder, that ‘fans’ get displayed the questions (xProfile-fields) for ‘teams’ was well; and the ‘teams’ the questions for ‘fans’…

—

Further problem:

Even if there is a solution regarding later profile edits – even complicate seems to be, to make already the registration page “input senstive”, because during registration the new user isn’t yet registered (i.e.: has no user role yet).

Cfr. there:

http://forum.wpde.org/buddypress/133961-registrierungsseite-umgestalten-anleitung-und-fragen.html (section 4. – unfortunately in German).

“probably need to pass to it bp_displayed_user_id()”

@hnla is correct, you will need to use bp_displayed_user_id()

as in:
`$user_id = bp_displayed_user_id();`

if displaying on their profile page then I don’t think you really need to loop over an array of user_id’s/roles, if you indeed do need to instantiate a new user then you probably need to pass to it bp_displayed_user_id()

You should be able to see what you have in the $user by var_dump – ing it out to see what it has

You could always edit the template files for /members/single/ (in a child theme) and wrap default actions in something like :

`if( ‘1’ == bp_displayed_user_id() )`

As a check for the displayed user being ‘1’ or primary network super_admin then you’ll do stuff based on that such as unique markup for that user alone or use in a ‘if not’ manner to hide certain profile display elements.

That’s a basic approach you could extend that to be more flexible by checking a users role bp_displayed_user() checked against WP roles and capabilities for that user.

@djpaul

You once mentioned having a proprietary solution for user lists using xprofile fields.

In redesigning my organization’s website I need to 1. display certain users (organization members in various departments) in a directory and 2. limit certain kinds of content creation to these lists (group creation only for organization members). We still want the site open to the public and use it to recruit new staff so I can’t just close down registration. Also, I can’t use wp roles because write permissions don’t line up with our organizational groupings (eg, some organization directors will be contributors while others are editors).

I’d be interested to know what you’ve come up with and would be willing to purchase it if it meets our needs and fits our budget.

Ice-cream sundaes! Oh yes! Actually, that’s one direction Drupal has been going (not the ice-cream, sadly), which is the eventual simplification of data storage. The biggest problem now, I think, is that developers map their views to data, and vice-versa. Drupal stores everything and anything as a ‘node’. So a node can contain one word, a site link, a story, a page, images, files, or any combination of all by having nodes within nodes. Its Views module then allows you to say how nodes are displayed; as blocks (widgets), pages, in tables, rows, any kind of custom layout.

What I’m visualising at present is a way of doing things like BP’s activity stream, where data is any kind of node you like, and you decide whether nodes can overflow or are cut (eg., large images), displayed all at once or shown as a bite (eg., stories/pages and small excerpts with ‘read more…’) etc. You then just decide whether each site page appears as a single page, a list of related nodes kinda bloggish, a list of related nodes a-la activity stream, etc. A couple of clicks could create a stream, a shopping page, or whatever you wish. Users then have BP style filtering links, so they can view everything the view shows, just friend’s contributions, just their groups, etc. Off-site information can be pulled in via links as well, and displayed as the same kind of node (similar data, just a different source). Wrap all that around an individual member with a profile and roles/permissions, and you have the most powerful and adaptable social network there is.

As I say, you can do that with Drupal, but gawd is it time consuming for a large project. I like the way WordPress is going, and if BuddyPress follows suit in the simple and easy to use stakes, the two combined will be amazing.

I’m no guru, so I hope someone else comes along to help more. However, what Justin indicated in his post should work for BP just like WP. In fact the “role” is created in WP through Members Plugin anyway.

I would play with echoing the member role name (assuming you’ve assigned one). Once that is echoed, you should be able to use a function based off the thread to assign a ‘$role’.’.png’ file for the icon. It shouldn’t matter that it’s the profile page unless there is a loop problem with that page.

If you have an appropriate development environment, Justin will probably help you get the Members plugin to echo the role on a WP page , but he’s not a BP guru, so you may be back here for the second step.