BuddyPress.org

HI,

perhaps because back-office actions are generally not public. Why would a site admin send mails to his site members after a back-office action ? Eventually interesting if you’re working with an admin team, but as this is not the most used workflow, why should this be part of BP ?
It is also not part of WordPress.
So i guess it is plugin territory, but i’m not aware of any existing for this.

In brief, yes ! Because a BP member is already a regular wp user. As soon as you register to a wp site, you became a wp user, whatever the plugin(s) you use.
Historically, WP is a CMS specialized in blogging… and is still this today… even if it can do much more as in 2003. But if we can today customize theme from within the wp-admin, we’re still confronted to a vintage user manager. Don’t know why, but outside subscriber, author and such (in fact, readers and newspaper actor’s terminology), there is not much you can do (simply) with “users” or “members”…

Perhaps you need some documentation to understand. WordPress distinguish users by roles and access capabilities. There is no “member” consideration. Member is a frontend term who sounds better as subscriber or editor when associated with a plugin like BP0. The term sounds also more accurate when you promote a “crew”, a “team” or a “community”. But technically, there is only a user with a role in WordPress, not a member.

https://codex.wordpress.org/Roles_and_Capabilities
https://codex.wordpress.org/User_Levels

Did you checked your WordPress time settings ?
What is your server time ?
Since when do you have that issue ?
Do you use a new plugin ?
Have you changed your theme ?
Have you add a custom function somewhere ?
Have you tested by using a twenty theme ?

For the moment, don’t panic. There is no problem in any js file on a common WP/BP installation. 😉

Hi,

BuddyPress doesn’t handle users. It use WP’s user_table and user_meta and his own meta tables (bp_activity_meta or bp_notifications_meta).

In BP settings, you have an option to sync BP to WP profile’s. And that’s all.

If you have another plugin who’s is synced with WordPress profiles, guess it will do the same with BP. But, adding a custom member table only for BP usage within WP registration process isn’t a good idea as you probably will have to rewrite a lot of code.

Members are the heart of BP, but in the sense of “how to show members and let them work together”, not in the way to include/register them to the site.
BP doesn’t never affect the first step when accessing the WP user registering. This step belongs clearly to WP ONLY. Adding member and meta tables doesn’nt modify that.

There’s quite a few privacy plugins for BuddyPress, just search the WordPress Plugins directory for BuddyPress and Privacy

@rickaltman – I think buddypress can do most of what you describe here right out of the box. I would search for forum threads and maybe plugins to have your members auto join a group –
this would give you something like “your site dot com / groups / mainGroupName / members
for this kind of list – although it would be a list rather than grid system – you may find another way to do it, but it’s probably gonna take some hacking-up things to get the grid layout if you really want that – I’d try to find something less robust – like maybe just the wpmudev membership2 plugin in the wp repo – and hackup a page to list authors with a wp theme or something…

bp can do a profile pic.. but it needs plugins to really “upload photos” – and that’s a can of worms in which some is over-baked, some under baked, and future possibilities are endless.. some built in bp hooks have been made a while back but.. well not sure what meant exactly by “upload photos” –

its going to be much easier to get community support for regular wordpress themes and such.. buddypress is probably a lot more power than your use case is gonna need.. and with that is gonna be spam issues – virtually no support for customizing anything.. even if you knew php really well, you’d have learn wordpress well, and then try to digest all the BP docs and sort through tracs.. gits.. and other random stuff on the web that is not well documented, no well supported, and leaves you wondering if it’s secure… and the chances of all the various hackedup things working well together is blah… and future updates – hahaha.. who knows that is going to happen.

In your situation I’d say it wouldn’t hurt to play around with BP – as it’s free.. but if it doesn’t do what you want out of the box.. then I would delete it all – and try a basic wordpress with members plugin.. maybe even just a ‘multi-author blog” – you’ll get less spam, and much less work.

Others may think / feel differently about all this, my experience comes from my issues – your mileage may vary..

Thank you for these clarifications.

It was not a BuddyPress issue and not a WordPress issue (as first expected), but a simple php error in a custom file. Little cause, big disease…

This is a lesson for all of us: whatever you code, take care with it. A missing dot, coma or other little syntax error can lead to endless searches, heavy expectations and massive headaches!

Hi,

BP devs are aware of this detail… Please read https://buddypress.trac.wordpress.org/ticket/7392

In which file are you seeing bp_before_displayed_user_fullname ?

It’s probably a wordpress do_action hook.
https://developer.wordpress.org/reference/functions/do_action/

You can activate wp_debug mode.

Hi,

BuddyPress follow your wordpress registration settings. Some other details can be found here:

Registration

Modifying the Registration Form

Hum, i have not noticed such an issue on any of my BP sites, what ever theme i use…
Have you tested with all plugins deactivated ?

Afaik you have to debug properly.
Use WP and BP only, with Twenty Sixteen and wp_debug activated.

https://codex.wordpress.org/Debugging_in_WordPress

Read also here and give details.

@deunit,

it’s not an issue but eventually an enhancement.
As nothing new appeared in the plugin sphere, and if you don’t know further, follow Shane’s recommendation.

To monetize your BP, perhaps you can consider MyCred ?

Closing this tread now.

Hi,

you have many errors in your code.

– in the css you declare a class (a dot ) while you use an ID (#) in the html
– in the code, you omit to close a p tag, and you need also a user_id and a way to get the displayed user (WordPress) role. Both are missing.

Here, the whole thing corrected.
– we don’t need a extra div, as we only add a p tag in an existing div.
– the code to get the role holds in 2 small lines.

The CSS (goes into child theme’s style.css)

#item-header-avatar p {
margin: auto;
border:1px solid green;
background: yellow;
width: 110px;
text-transform: capitalize;
}

The html and php for the template (starts aroud line 24 of cover-image-header.php)

<div id="item-header-avatar">
	<a href="<?php bp_displayed_user_link(); ?>">

	<?php bp_displayed_user_avatar( 'type=full' ); ?>
	</a>

	<?php
	$user = new WP_User( bp_displayed_user_id() );
	echo '<p>'. $user->roles[0] .'</p>';
	?>			
	
</div><!-- #item-header-avatar -->

Do it simple ! 😉

Please use the support forum for that plugin –
https://wordpress.org/support/plugin/bp-registration-options

Hi,

guess you confuse member types and user roles. MT where introduced to allow site owners to “categorize” their users. WP user role is slightly different, as it defines what user can do on a site, a kind of access management. So in brief, roles are independent from BP member types.

MT and roles are also stored in different tables: MT in wp_terms and roles in wp_usermeta – with the denomination of wp_capabilities…

By default, roles are automatically attibuted at registration level or manually by a site admin. Member types follow the same logic, under condition the xprofile component is activate.

Now the question is: what do you want to do exactly after registration ? Change the role or change the type ?

Roles can be affected from the admin user list page. I would recommand to not modify this behave at registration level, to avoid abuse by promoting fake user for example.

MT can be changed from the xprofile admin interface. There is also this plugin for a more in depth management.

Using a custom function is of course possible. But just to clarify, the one you give as example let’s suppose you have a need for bulk action over user status. Automated task is well and good, but in this case, why not attribute a higher role or type to all by default ?
And if it is not intended for “all” (what i suppose is the case), do you have so many exception that you need such a function ? Can’t you do that manually ? Just my 2 cents. 😉