Search Results for 'display user role on profile page'

Viewing 22 results - 26 through 47 (of 47 total)

← 1 2

Author

Search Results
November 12, 2015 at 12:10 am #246607

In reply to: Display image for paid members

gurusurfer
Participant

Just so to be clear since you mentioned the class!

I am not trying to show the image for paid members visitors here. I want to add an image for the member profile for any user to see when they land on their profile page.

If you are not familiar with the above tag, do you have a suggestion how I can display an image icon for user profiles of custom role?

Many thanks

October 1, 2015 at 10:41 pm #244990

In reply to: Hide profile tabs on user roles
shanebp
Moderator
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.
May 26, 2015 at 9:54 pm #239721

In reply to: Buddypress – how to display user role on profile page?

danbp
Participant

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/

May 23, 2015 at 8:14 am #239561

In reply to: 2.2 Member Types – Setting user member types during registration (xProfile)
danbp
Participant
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.
February 7, 2015 at 1:28 am #234013

In reply to: Custom Post Type Support for Activity

Mathieu Viet
Moderator

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.

January 21, 2015 at 10:14 pm #232703

In reply to: How to hide section of profile to all but that user and admin?
Henry Wright
Moderator
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' );
```
November 29, 2014 at 10:44 am #229903

In reply to: [Resolved] Notification – what's wrong here?
miama
Participant
```
<?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’ ); ?>
```
October 8, 2014 at 9:00 pm #207114

In reply to: Profile fields for locations within a country
1a-spielwiese
Participant
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).
October 3, 2014 at 8:59 am #203649

In reply to: Reshaping the registration page

1a-spielwiese
Participant

Let’s come back to the beginning:

1st: Revolved.

2nd: Resolved.

a) I decided finally for having only one border color. If you want to have different border colors, you have to make different definitions for #buddypress .standard-form #basic-details-section and #buddypress .standard-form #profile-details-section

and, if you use them, for: #user-role-section and #buddypress .standard-form #blog-details-section.

b) I have abstained from having the text lines ‘WordPress’ respec. ‘BuddyPress’ at the borders and from making the bottom-borders more strong.

3rd: Revoled.

4th: Revolved.

5th:

I guess, it would be most comfortable, to have within the Dashboard check boxes for deciding, whether a certain field group or field should be displayed on registration page or not.

Not revolved.

6th to 8th:

a) Finally I have abstained from having the blog-details-section on the registration page.

b) I didn’t collect information about changing this section.

—-

So, the main issues are revolved. I would have no objections against marking the entire thread as ‘[Resolved’].

October 2, 2014 at 5:19 pm #203615

In reply to: Reshaping the registration page
1a-spielwiese
Participant
I found two more solutions:

1st:

a) The place of the field for determining the user role is depending on the plugins/wp-roles-at-registration/wp-roles-at-registration.php

The relevant line of the original version of that file is:

add_action('bp_after_signup_profile_fields', array($wp_rar_plugin, 'bp_choose_roles_registration_form'));

I substituted there bp_after_signup_profile_fields by template_notices and now the field at issue is displayed not the end, rather at the beginning of my registration page:

http://1a-spielwiese.de/registrieren/

b)

For creating the headline and the introductory text I made a second change within the same file. I changed the following section. The first and the last line of the quote is the original code, and the lines inbetween I inserted:
```
    <div class="register-section" id="user-role-section">
    
    <h4-a><?php _e( 'Benutzer/in/rolle', 'buddypress' ); ?></h4-a>

    <p><small><em>Entscheide Dich bitte als allererstes f&uuml;r eine der Benutzer/in/rollen "Team" oder "Fan" (bitte w&auml;hle nicht die Rolle "Subscriber"; diese Angabe soll noch gel&ouml;scht werden). In Abh&auml;ngigkeit von Deiner Antwort wirst Du nach Abschluss der Registrierung und wenn Du Dich das erste Mal bei 1a-Spielwiese einloggst und Dir Dein Profil ansiehst, die M&ouml;glichkeit haben, einige erg&auml;nzende rollenspezifische Profilangaben zu machen.</em></small></p>

    <label for="wp_rar_user_role"><?php echo $this->wp_rar_role_label; ?></label>
```
2nd:

As well I was able to integrate now not only the ‘base’-profile field group. For that it is neccessary to copy a long section of the buddypress register.php. This sections begins with:
```
			<?php /***** Extra Profile Details ******/ ?>

			<?php if ( bp_is_active( 'xprofile' ) ) : ?>

				<?php do_action( 'bp_before_signup_profile_fields' ); ?>

				<div class="register-section" id="profile-details-section">

					<h4><?php _e( 'Profile Details', 'buddypress' ); ?></h4>

					<?php /* Use the profile field loop to render input fields for the 'base' profile field group */ ?>

					<?php if ( bp_is_active( 'xprofile' ) ) : if ( bp_has_profile( array( 'profile_group_id' => 1, 'fetch_field_data' => false ) ) ) : while ( bp_profile_groups() ) : bp_the_profile_group(); ?>
```
And it ends with:
```
					<input type="hidden" name="signup_profile_field_ids" id="signup_profile_field_ids" value="<?php bp_the_profile_field_ids(); ?>" />

					<?php endwhile; endif; endif; ?>

					<?php do_action( 'bp_signup_profile_fields' ); ?>

				</div>

			<?php endif; ?>
```
The only two things, which are obligatory then:
- You have to insert the entire copied section behind the last line of the original section.
- And you have to change 'profile_group_id' => 1, into 'profile_group_id' => 2, (for adressing your second profile field group – and so on regarding the further profile field groups).
Besides I changed the <h4>-headline and inserted introductory text behind that headline. Therefore my code there is:
```
					<h4-a><?php _e( 'Profile Details - Teil II: Kontaktendaten', 'buddypress' ); ?></h4-a>

				<p><small><em>Beachte bitte, dass Du in zu den Profilfeldern in diesem Abschnitt selbst entscheiden kannst, wem Deine Angaben, die machst, angezeigt werden sollen.</small></em></p>
```
September 29, 2014 at 9:28 pm #202778

In reply to: Reshaping the registration page
1a-spielwiese
Participant
I decided to test theses instructions – and in general they work.

My registration page has now a new design:

http://1a-spielwiese.de/registrieren/

This result I got using two means:

1st:

I tested with ‘Simple Custom CSS’-Plugin that code:
```
#buddypress .standard-form #basic-details-section, #buddypress .standard-form #blog-details-section, #buddypress .standard-form #profile-details-section {
    border: 2px solid #8b008b;
	float: none;
  	clear: left;
  	width: 100%;
  	padding: 10px;
  	margin-bottom: 1em;
}

#user-role-section {
  	border: 2px solid #8b008b;
    float: none;
    width: 100%;
  	padding: 10px;
}

#wp_rar_user_role {
      width: 100%;
    }

h4-a {
	color: #8b008b;
	font-size: 11px;
	font-size: 1.1rem;
  	font-weight: bold;
	letter-spacing: 0.05em;
	line-height: 1.9091;
	text-transform: uppercase;
}

.wp-editor-container {
    border: 1px solid #DCDCDC;
}
```
Finally I will insert it into my child-theme.

2nd:

The relecant section of the register.php with in my reddle-child/buddypress/members-folder is now:
```
		<?php if ( 'request-details' == bp_get_current_signup_step() ) : ?>

			<?php do_action( 'template_notices' ); ?>

			<p><?php _e( 'Mitglied bei 1a-Spielwiese zu werden, ist sehr einfach - und kostenlos. F&uuml;lle einfach die Felder unten aus und wir erstellen f&uuml;r Dich umgehend ein Benutzer/in/konto und in K&uuml;rze auch einen eigenen Blog (Webseite).', 'buddypress' ); ?></p>

			<?php do_action( 'bp_before_account_details_fields' ); ?>

			<div class="register-section" id="basic-details-section">

				<?php /***** Basic Account Details ******/ ?>

				<h4-a><?php _e( 'Account Details', 'buddypress' ); ?></h4-a>

				<p><small><em>Diese Daten werden f&uuml;r Deine Registrierung als neues Mitglied und die Einrichtung Deines eigenen Blogs (Webseite) ben&ouml;tigt.</em></small></p>

				<label for="signup_username"><?php _e( 'Username', 'buddypress' ); ?> <?php _e( '(required)', 'buddypress' ); ?></label>
				<?php do_action( 'bp_signup_username_errors' ); ?>
				<input type="text" name="signup_username" id="signup_username" value="<?php bp_signup_username_value(); ?>" />

				<label for="signup_email"><?php _e( 'Email Address', 'buddypress' ); ?> <?php _e( '(required)', 'buddypress' ); ?></label>
				<?php do_action( 'bp_signup_email_errors' ); ?>
				<input type="text" name="signup_email" id="signup_email" value="<?php bp_signup_email_value(); ?>" />

				<label for="signup_password"><?php _e( 'Choose a Password', 'buddypress' ); ?> <?php _e( '(required)', 'buddypress' ); ?></label>
				<?php do_action( 'bp_signup_password_errors' ); ?>
				<input type="password" name="signup_password" id="signup_password" value="" class="password-entry" />
				<div id="pass-strength-result"></div>

				<label for="signup_password_confirm"><?php _e( 'Confirm Password', 'buddypress' ); ?> <?php _e( '(required)', 'buddypress' ); ?></label>
				<?php do_action( 'bp_signup_password_confirm_errors' ); ?>
				<input type="password" name="signup_password_confirm" id="signup_password_confirm" value="" class="password-entry-confirm" />

				<?php do_action( 'bp_account_details_fields' ); ?>

			</div>

			<?php do_action( 'bp_after_account_details_fields' ); ?>

			<?php /***** Extra Profile Details ******/ ?>

			<?php if ( bp_is_active( 'xprofile' ) ) : ?>

				<?php do_action( 'bp_before_signup_profile_fields' ); ?>

				<div class="register-section" id="profile-details-section">

					<h4-a><?php _e( 'Profile Details', 'buddypress' ); ?></h4-a>

				<p><small><em>Diese Daten werden k&uuml;nftig in Deinem Profil angezeigt. Einige Angaben sind verpflichtend, um aussagekr&auml;ftige Profile zu erhalten; bei anderen Formularfeldern ist es Dir selbst &uuml;berlassen, ob Du Angaben machst oder nicht.</small></em></p>

					<?php /* Use the profile field loop to render input fields for the 'base' profile field group */ ?>

					<?php if ( bp_is_active( 'xprofile' ) ) : if ( bp_has_profile( array( 'profile_group_id' => 1, 'fetch_field_data' => false ) ) ) : while ( bp_profile_groups() ) : bp_the_profile_group(); ?>

					<?php while ( bp_profile_fields() ) : bp_the_profile_field(); ?>

						<div<?php bp_field_css_class( 'editfield' ); ?>>

							<?php
							$field_type = bp_xprofile_create_field_type( bp_get_the_profile_field_type() );
							$field_type->edit_field_html();

							do_action( 'bp_custom_profile_edit_fields_pre_visibility' );

							if ( bp_current_user_can( 'bp_xprofile_change_field_visibility' ) ) : ?>
								<p class="field-visibility-settings-toggle" id="field-visibility-settings-toggle-<?php bp_the_profile_field_id() ?>">
									<?php printf( __( 'This field can be seen by: <span class="current-visibility-level">%s</span>', 'buddypress' ), bp_get_the_profile_field_visibility_level_label() ) ?> <a href="#" class="visibility-toggle-link"><?php _ex( 'Change', 'Change profile field visibility level', 'buddypress' ); ?></a>
								</p>

								<div class="field-visibility-settings" id="field-visibility-settings-<?php bp_the_profile_field_id() ?>">
									<fieldset>
										<legend><?php _e( 'Who can see this field?', 'buddypress' ) ?></legend>

										<?php bp_profile_visibility_radio_buttons() ?>

									</fieldset>
									<a class="field-visibility-settings-close" href="#"><?php _e( 'Close', 'buddypress' ) ?></a>

								</div>
							<?php else : ?>
								<p class="field-visibility-settings-notoggle" id="field-visibility-settings-toggle-<?php bp_the_profile_field_id() ?>">
									<?php printf( __( 'This field can be seen by: <span class="current-visibility-level">%s</span>', 'buddypress' ), bp_get_the_profile_field_visibility_level_label() ) ?>
								</p>
							<?php endif ?>

							<?php do_action( 'bp_custom_profile_edit_fields' ); ?>

							<p class="description"><?php bp_the_profile_field_description(); ?></p>

						</div>

					<?php endwhile; ?>

					<input type="hidden" name="signup_profile_field_ids" id="signup_profile_field_ids" value="<?php bp_the_profile_field_ids(); ?>" />

					<?php endwhile; endif; endif; ?>

					<?php do_action( 'bp_signup_profile_fields' ); ?>

				</div>

				<?php do_action( 'bp_after_signup_profile_fields' ); ?>

			<?php endif; ?>

			<?php if ( bp_get_blog_signup_allowed() ) : ?>

				<?php do_action( 'bp_before_blog_details_fields' ); ?>

				<?php /***** Blog Creation Details ******/ ?>
```
3nd:

Nevertheless I have two questions regarding the design:

a) Why the 100%-width for #wp_rar_user_role is ignored?

b) How can I place the third section (‘Mitglieder-Kategorie’) above the other two sections (or between the other two sections)?

4th:

I recognised as well: Deleting there:

<?php if ( bp_is_active( 'xprofile' ) ) : if ( bp_has_profile( array( 'profile_group_id' => 1, 'fetch_field_data' => false ) ) ) : while ( bp_profile_groups() ) : bp_the_profile_group(); ?>

'profile_group_id' => 1, results in getting not only displaying the ‘base group’ of the xProfile fields, rather all fields of all field groups. 🙂

Questions:

a) How can I get the names (titels) of the different xProfile field groups displayed as well?

b) How can I ensure, that only new members, which choose the user role ‘team’, get displayed the profile fields for teams and new members, which choose the user role ‘fan’, get displayed the profile fields for fans?
May 1, 2013 at 3:38 pm #163198

In reply to: Is this how multisite registration is supposed to work?

Ben Hansen
Participant

thanks @hnla is there a way to make it add new users to main site automatically? i’ve noticed certain things aren’t working quite right such as new users ability to view forums (have no role) and display of usernames on the profile page when the user is only a network user.

May 6, 2012 at 11:40 pm #134107

In reply to: Display user role on profile page

@ChrisClayton
Participant

“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();`

May 6, 2012 at 6:43 pm #134087

In reply to: Display user role on profile page

Hugo Ashmore
Participant

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

April 17, 2011 at 11:45 am #110456

In reply to: Admin Profile page

Hugo Ashmore
Participant

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.

March 11, 2011 at 6:09 am #107499

In reply to: BuddyPress throwing 404

mwp
Member

I had to reinstall wordpress. I got tons of errors when I try to add buddypress plugin in the latest 3.1 wordpress:

Notice: Undefined offset: 0 in /var/www/html/site/wp-content/plugins/buddypress/bp-core/bp-core-catchuri.php on line 85

Notice: is_page was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. (This message was added in version 3.1.) in /var/www/html/site/wp-includes/functions.php on line 3422

Notice: Undefined offset: 2 in /var/www/html/site/wp-content/plugins/buddypress/bp-core/bp-core-catchuri.php on line 158

Notice: Undefined property: stdClass::$loggedin_user in /var/www/html/site/wp-content/plugins/buddypress/bp-forums.php on line 530

Notice: Trying to get property of non-object in /var/www/html/site/wp-content/plugins/buddypress/bp-forums.php on line 530

Notice: Undefined property: stdClass::$displayed_user in /var/www/html/site/wp-content/plugins/buddypress/bp-core.php on line 1070

Notice: Trying to get property of non-object in /var/www/html/site/wp-content/plugins/buddypress/bp-core.php on line 1070

Notice: Undefined property: stdClass::$profile in /var/www/html/site/wp-content/plugins/buddypress/bp-xprofile/bp-xprofile-classes.php on line 816

Notice: Constant BP_XPROFILE_BASE_GROUP_NAME already defined in /var/www/html/site/wp-content/plugins/buddypress/bp-xprofile.php on line 101

Notice: Constant BP_XPROFILE_FULLNAME_FIELD_NAME already defined in /var/www/html/site/wp-content/plugins/buddypress/bp-xprofile.php on line 102

Notice: Undefined index: fileupload_maxk in /var/www/html/site/wp-content/plugins/buddypress/bp-core/bp-core-avatars.php on line 35

Notice: Undefined property: stdClass::$current_group in /var/www/html/site/wp-content/plugins/buddypress/bp-groups.php on line 223

Notice: Trying to get property of non-object in /var/www/html/site/wp-content/plugins/buddypress/bp-groups.php on line 223

Notice: Undefined variable: count_indicator in /var/www/html/site/wp-content/plugins/buddypress/bp-messages.php on line 115

Notice: Undefined index: action in /var/www/html/site/wp-content/plugins/buddypress/bp-core/bp-core-signup.php on line 571

Notice: has_cap was called with an argument that is deprecated since version 2.0! Usage of user levels by plugins and themes is deprecated. Use roles and capabilities instead. in /var/www/html/site/wp-includes/functions.php on line 3387

October 19, 2010 at 7:24 am #95550

In reply to: Multiple user types – possible?

Matt Edminster
Participant

@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.

June 29, 2010 at 6:17 pm #83447

In reply to: Removing Groups From Forums

lincme.co.uk
Member

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.

June 23, 2010 at 7:13 pm #82429

In reply to: Link Directly to Blogs' Author Posts

Nahum
Participant

@r-a-y i have a tough time understanding it myself! just crazy tinkering I guess, there is probably a simple solution….

I think you’re right about super admin.

I’m talking more about other members, who have posted on other network blogs. If you look at my profile sidebar, you’ll see “my videos” and “my posts” links. Each should take you to the author template page for those members on the corresponding blogs.

My Videos ==> site.com/author/ray
My Posts ==> site2.com/author/ray

get_blogs_of_user method works to display only the sites members have posted on sitewide – it will however show primary site of a member regardless of posts.

get_blog_details method forces all member profiles to display the links regardless of having posts or not. It will just link to the author page with “no posts for this author’ message as part of the author.php template.

the issue i’m having with get_blogs_of user, I have users who make one time posts by way of a frontend form. They own that post but they don’t have a role on the blog. I think that is the reason why on some users, the links don’t display even if they do have posts.

both methods are useful depending on how you want to use them.

i’d like to be able to use the get_blog_details method because it lets me define what links to display. and the issue i have with that is that the links are always present, I’d like for them to only show up if the user has posts.

make less sense now! hehe, anyway it is a very specific feature, some people may like to do something like this.

December 2, 2009 at 9:40 pm #57919

In reply to: How do you display user roles in BuddyPress public profiles?

designodyssey
Participant

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.

October 29, 2009 at 12:02 am #55377

In reply to: Filter members by custom fields
buzz2050
Participant
Well, I would be happy to share the solution, but I don’t really think my way is all that elegant, there’s got to be a better way and I’m waiting for someone to suggest it to me.

Meanwhile, I am still using the old 2-theme model. I made some customizations in my bpmember theme to achieve this and put in some code in plugins/bp-custom.php as well.

Firstly, we have a custom profile field called ‘Role’. And we wanted to have separate Role-tabs (as you can see on our site) to list all members for THAT role.

To achieve this, I completely changed the bpmember/directories/members/index.php code and put in my ‘Role’ tab-structure there. Then, instead of making the members index file call the members-loop, I wrote a modified version of the members-loop, made it as a function and put it in my bp-custom.php. Now I make a call to this function (which is basically the members-loop) from my bpmember/directories/members/index.php page.

To give you an eg of how we display all companies under the Company tab:

In my bpmember/directories/members/index.php, under the code section for ‘Company’ tab I make a call like:

display_members_by_role(‘Company’);

In my bp-custom.php, I have written a function display_members_by_role($role) which is nothing but a slightly modified version of the members-loop.

Here, in the ‘while’ for members-loop, I check for the Role field for that user-id. For this eg, if the Role is ‘Company’, print that member in the company-listing, else not.

This is the code I have put in the members-loop which checks the custom profile field (which is this case is ‘Role’) and it’s value for that user-id:
```
...

...

<?php while ( bp_site_members() ) : bp_the_site_member(); ?>



<?php

global $site_members_template ;



$arr = BP_XProfile_ProfileData::get_value_byfieldname(array('Role'), $site_members_template->member->id) ;



if( $arr['Role'] == $role) //$role is the role value received by the function, in this eg - Company

{

//do whatever

}

<?php endwhile; ?>

....

....
```
Same logic is used for all other roles.

BTW, get_value_byfieldname() can return values for multiple fields too. In case you want to retrieve values of more than one profile fields, its easily possible. Say I want the ‘City’ custom field value too, then I would pass something like –

$arr = BP_XProfile_ProfileData::get_value_byfieldname(array(‘Role’,’City’)

and access the ‘City’ value using $arr[‘City’]

This function is pretty handy.

While I am able to print the members belonging to that corresponding role using this logic, what I can’t get into place is the pagination part. The pagination still takes into account ‘All’ members since the members-loop technically does retrieve all members.

All I have done is put a condition in order to just get the members for that role displayed. I was wondering if I should put in a separate pagination module, or if there is any other way of achieving this whole thing.

-Sib
July 15, 2009 at 7:22 am #49346

In reply to: New Groupblog Plugin

Mariusooms
Participant

Good idea r-a-y! It is summer vacation now, but I will definitely include some as our users start building their profile and groups with this plugin. These are some upcoming feautures:

* Construct the group_id, this allows us to switch blogs in the group and pull in the relevant information. (done)

* Construct the reverse blog_id, this allows us to have group based loops in the blog to display members, profile, activity etc based on the group id. (done)

* Allow blog registration at group sign up, much like how you can create a blog at site registration.

* Add members silently to the blog when they become group members.

* Different role caps depending on role within the group. By default members are authors, mods are editors and admins are admins.

* Allow the admin set role caps on group roles, e.g. the group admin only want its members to be subscribers. Or editors for a wiki type solution.

* Have an option to disable silent adding of members in case the group admin only wants (or needs) the group blog be accessible by him (or her).

* Create more templates. One we have now is a simple template that creates a menu from the page titles, which allows the group to behave like a cms.

We will also offer some blog templates to help make the blog look transparent to the information you display within the group so its transition from group to blog nad vice versa is seemless.

Thanks for your interests already.
Author

Search Results