BuddyPress.org

Yeah, I’d check the BuddyPress User Handbook first. it should cover both setting up the buttons and making the signup fields actually editable.

Yeah, I’d avoid editing the BuddyPress plugin file directly too, since an update could overwrite the change. I’d first check whether the theme is overriding the avatar template, and if not, Loco Translate sounds like a cleaner way to change that text.

With a few exceptions, those who are “Moderators” and “Keymasters” are members of the BuddyPress development team.

Having stated the above, you are welcome to open a New Ticket because this has run its course as a forum topic.

The missing BuddyPress cookie is the main clue. The request returns 200 but no group is created,test the server-side flow first.

Temporarily disable Youzify and LiteSpeed Cache, then try /groups/create/ with BuddyPress’s default templates. If it works, re-enable them one at a time to find the conflict. Also check your hosting PHP error log for any failed hooks or permission checks.

You’ve already ruled out the theme and plugins, checking the BuddyPress server-side logs would probably be the best next step to see why the group creation request is being rejected.

I agree, having everything under one BuddyPress menu would make the dashboard much cleaner and easier to navigate. It would also make it simpler for new users to find the settings and features they need.

IIRC, they were separate from BP 0.x era because they were individual mu-plugins supposed to work without other parts. Andy was adding them one by one, and menus were being added separately as well. Release of v1.0 just solidified this historical decision.

I’d love to see BuddyPress menu unified as a single top-level menu item.

You might want to consider contacting BuddyBoss for support. These forums are for BuddyPress, which is not BuddyBoss.

I wouldn’t treat “one flow or one flow per role?” as a strict either/or.

WordPress’s own permissions model gives quite a useful way of thinking about this. A role is basically a bundle of capabilities; when WordPress needs to know whether somebody can actually do something, the useful question is the capability and sometimes the particular object/context—not merely the role name.

I think onboarding benefits from the same approach. Have one underlying onboarding system, but make its steps conditional on what this user can do, what state the account is in, and what their next useful task is.

So an admin might branch immediately into workspace setup and invitations, a team member into completing their first real task, and a viewer into finding and understanding the information they’ve been invited to see. Shared steps can remain shared; there’s no need to maintain three completely independent journeys.

It also means you can progressively reveal things. If the viewer can’t configure the workspace, don’t teach or foreground those controls. If a team member later gets a new capability, introduce the relevant feature then rather than making them sit through it during initial onboarding.

On WordPress I’d also be inclined to branch on capabilities rather than hard-coded role names wherever the distinction represents an actual permission. If BuddyPress Member Types are being used, those can describe what sort of member someone is, while capabilities describe what they can do. Those are usefully different questions.

So I’d probably describe the architecture as shared flow + conditional modules, rather than either “one onboarding for everybody” or “one completely separate onboarding per role.”

Milestone 14.5.3 is up next and “soon” would be relative to the observer. All I can say is that the target date is set for August 29, 2026.

As for the Wordfence notice, I’m not at liberty to discuss in public. WordPress has an account on Slack, here is some information regarding such (there are numerous channels including those for BuddyPress and bbPress):

WordPress Chat
Join the WordPress community

Assuming the site is set up for “Membership Requests”, the other admins can just “opt-out” of receiving the email notifications.

However, if you are looking for a coding solution, the bp_members_membership_requests_notify_site_admins() function should provide the information for implementing such. See the following link:

https://github.com/buddypress/buddypress/blob/80aa6969164c956a8d761671cd7652bbd2240d4e/src/bp-members/bp-members-membership-requests.php#L156

If editing the template file didn’t change the text, it’s likely being generated by BuddyPress core or a filter, not that specific template.

I’d recommend checking for a hook such as bp_core_avatar_admin or overriding the string with a translation plugin like Loco Translate. That approach is usually update-safe and avoids editing plugin core files. If you’re using a custom theme, also make sure it isn’t overriding the BuddyPress template.

There is more to your story than you are revealing. What is the version of BuddyPress?

My point is that this doesn’t appear to be a BuddyPress issue. If you create a WordPress post and that post shows up as a BuddyPress activity, then the tracking is working, regardless of whether featured images are showing within an Activity item as delayed as opposed to instantly.

IOW, the issue appears to reside with FIFU itself or networking issues that are causing the delay (since images are sourced externally).

If you still believe that this is a issue with BuddyPress then I suggest that you open a ticket and provide facts that support your claim.