BuddyPress.org

Perhaps that filter hook is for filtering embeds in WordPress content? BuddyPress must have a filter for this. I’ll need to have a dig around…

Why not making your member directory alphabetical by default ?
Add this to members-loop placed in /child-theme/buddypress/members/members-loop.php:22

<?php if ( bp_has_members( bp_ajax_querystring( 'members' ) . 'type=alphabetical' ) ) : ?>

Members Loop

Note:
– member must be approved (by validation mail or admin action) to appear in the list.
– default behave is that a new member only appear on directory after his first login.

Hi @bazingauser,

try this solution and give feed back

https://buddypress.org/support/topic/suppressing-rich-text-on-xprofile-text-area/#post-247640

Try enabling a BP_ENABLE_USERNAME_COMPATIBILITY_MODE: https://codex.buddypress.org/getting-started/customizing/changing-internal-configuration-settings/

What version of WordPress, BuddyPress, are you using?

What theme, and what other plugins do you have active?

Ah, what’s the profile field type for that? Is it a date field type or a “Birthday” field type?

Are you using the https://wordpress.org/plugins/buddypress-xprofile-custom-fields-type/ plugin ?

@schweizersolutions With your current solution:

1) If BuddyPress is loaded in this context, I’d strongly recommend you use bp_update_option instead of update_option as this supports all the different configurations of BuddyPress install/configuration.

2) If you look at bp_version_updater or bp_core_admin_components_settings_handler for example, it does what you’re doing, but it runs the installation routines afterwards. I’d recommend you copy the logic from bp_core_admin_components_settings_handler.

3) An alternate approach is to filter the bp_new_install_default_components array as long as you can put that in place before BuddyPress loads.

4) I think activated_plugin might be too early, i.e. before BuddyPress installs. I am not sure, I can’t test right now. BuddyPress’ core routines start from plugins_loaded, and I think that’ll have already be triggered before activated_plugin, so the behaviour will be undefined (i.e. it might install on the next page load, or part-install immediately, and I have no idea if this will break stuff).

Hope this helps

BuddyPress will try to sync the value of a user’s “Name” field to the First and Last Name fields in their wp-admin user profile.

To disable this, go to wp-admin Settings > BuddyPress, and disable Profile Syncing.

The Object Cache feature inside W3TC is not compatible with BuddyPress. It does not work properly.

BuddyPress is solid, shared hosting is cheap but there are many alternatives. Do some research with different hosts and see what they can offer you.

@mohammad-sy,

you can filter the activity stream. Read here:

Using bp_parse_args() to filter BuddyPress template loops

You’ll also find many snippets on the forum by searching for “_parse_args”.

Updates are an activity type ! This is already available in the activity filter.

@mugwumpman,
first and last_name fields don’t belong to BuddyPress, but to WP profiles.

BP use only a field called Name at first install. User can enter their first AND last name in that field. Is this what you’re talking about ?

After reading your topic on wp.org, it seems that you use those fields to enter datas which are not first and last names, but more for company and company activity or such.

As you use BP, i would suggest you use the power of xprofile and offer to your user a much better experience by adding a field for a company and another for company activity (or something like that). So you can forget WP’s profile fields and use BP’s xprofile fields.

WP’s profile field used when BP is activated are: username, email and password.
And BP adds his mandatory Name field, which can be first, lastname, username or whatever other unique name belonging to a subscriber (which can be a human, a pet, a company….).

And yo can as many fields you want to the registery or for later on profiles.

The other problem related to font case is a mistery so far. Can be related to many things such as plugins or theme or custom function. This can be determined by debuging and using one of WP’s default theme and all plugins deactivated.

No matter to know if you fill a wp or a bp field for this. Both use a textarea, so it’s probably more a css thing somewhere.

See in bp-templates/bp-legacy/buddypress/members/single

and read here for some general guidance. Note: even if only Twenty theme are described as example, you can use (more or less) the same technique for any other theme.

What ever, all starts by creating a child-theme as very first step.

Related to your question, do drop down list of the sub nav and hide them in the object nav fields, i think you don’t need to alter a template, but to write a custom function.

As i can be wrong about you goal, perhaps take also a look to core file bp-core/bp-core-buddybar.php to understand how nav and subnav are instanciated.

Read also https://codex.buddypress.org/developer/navigation-api/

@fearthemoose, a solution is partially given in this topic. Check just the correct way to write the function from here:

BuddyPress Cover Images

It’s important also to try first with a Twenty theme, as the issue could came from your theme or another plugin as BP.

I posted the final bit of my solution to this problem over on BBPress Ticket #2191 here:
https://bbpress.trac.wordpress.org/ticket/2191#comment:17

It’s filter code that helps bbPress to know what BuddyPress group is associate with any activities that might happen in a sub-forum.

So the BuddyPress group still has just one forum, but that one forum can have multiple sub-forums.

[URL’s removed] by user request.
Only 5 tickets of your’s on Trac: https://buddypress.trac.wordpress.org/search?q=dono12

Regarding my caveat above (that BP activities were not showing up in the BP news feed of a non-admin user), I have discovered that two other plugins I have been using are effecting the behavior here:

1. BuddyBoss Wall: this is not breaking anything, but it does change what the activity stream looks like to the user. In particular, it adds a “news stream” view, similar to Facebook. So for anyone reading this later wondering what I meant by “news stream” above, that’s apparently a BuddyBoss Wall specific view.
2. BuddyPress Activity Privacy: It was when I disabled this plugin that the non-admin user started seeing the activity updates in his news feed as I would have expected. And I’m not saying that this plugin was breaking anything necessarily—could easily have just been some configuration mixup on my part. But it was time for me to remove this plugin anyway because it was adding unnecessary complexity to my site.

So removing the Activity Privacy plugin resolved the caveat. Scenario 4 is now working for me just as I need it to.

Thanks for the suggestion, @earl_d. I had tried it already, but at your suggestion, I tried again. I did find one user error on part that was partially responsible for the fact that it didn’t work previously (the root group forum had a visibility of “Hidden”, which breaks makes the topic inaccessible to non-admin users). But still, your suggestion didn’t work for me.

TLDR: I got it working, mostly, though not entirely, and not using the approach you suggested, but your suggestion sent me down a fruitful path that ended up working out. See Scenario 4 below. Posting all of this for the benefit (hopefully) of others that may come along some day trying to work through the same issue.

(BTW, the way I interpreted your suggestion was that I should set the top-level group forum to have type=category instead of type=forum. In any case, here are my results…)

Versions

1. WordPress: 4.6
2. bbPress: 2.5.10
3. BuddyPress: 2.6.2

Scenario 1:
(a) Create the BP Group without an associated forum.
(b) Separately, later, create a forum with type=category
(c) Go to the BP Group’s settings to try and associate the Forum to the BP Group

Fail: The forum drop-down has the category forum greyed out, probably because it’s type=category.

Scenario 2:
(a) Create the BP Group *with* an associated Forum (which will automatically have type=forum)
(b) Separately, later, go edit that new Forum’s type, setting type=category
(c) Navigate to the forum’s page within the group. Say’s “the forum is empty.”
(d) Add a new sub-forum type=forum
(e) Create Topic A in the sub-forum
(f) Navigate to the group’s forum again (as a non-admin user)

Expected: Topic A should appear
Actual: Topic A does not appear

(g) How about directly linking to Topic A? Maybe Topic A is accessible to the user, but somehow the template simply isn’t outputting it under (f) above?

Expected: Topic A should be accessible
Actual: Topic A is accessible

Therefore: the user can see and interact with Topic, but BuddyPress doesn’t know about it as being part of the forum.

In retrospect, what seems to have actually happened here is that the original group of type=forum was regenerated and associated with the BP Group. So our topic is probably not showing up in the Group because it’s parent is the sub-forum of a forum the forum that is no longer associated with the group.

Scenario 3:
I thought: If sub-forums don’t work, then maybe multiple sibling forums could work. The Settings page for BuddyPress obviously only allows you to attach one forum, though the data model seems to allow for multiples. However, after slogging through the code, it’s clear that the current version of bbPress thwarts the adding of multiple forums. In at least two places that I saw in the code (like includes/extend/buddypress/groups.php), you have something like this:

// No support for multiple forums yet
$forum_id = (int) ( is_array( $forum_ids ) ? $forum_ids[0] : $forum_ids );

So even if you were to completely bypass the user interface and do a hack of some kind to attach multiple forums to the group, this sort of code would thwart the hack.

Scenario 4:
So what if we go back to Scenario 1, but set up the initial group-associated forum with type=forum, instead of type=category. It would then be selectable in the admin UI, or could just be created automatically upon creation of the group.

(a) Create a new private group with an associated forum
(b) Go create a new private forum and set its parent to be that initial group forum
(c) Create a topic in the sub-forum
(d) Navigate to the forum within the group as a non-admin user

Expected: The sub-forum should be visible and navigable
Actual: It is! The user can click through, see the topic within the sub-forum, and reply on it.

Conclusion: Success! This is the best and most functional scenario thus far.

Key differences from what I’d tried and failed before:

1. All forums involved have to be set to Private visibility. If Hidden, then some aspects of this may success, but others will fail.
2. The forum that is associated with the group will have to be type=forum, not type=category. But I wrote a little plugin that disallows creation of new topics within a forum, without having to mark it CLOSED (thereby also disabling comments). So this will functionally turn this top-level group forum into a category/container forum anyway

Caveat: I have noticed that when my admin user replies on the topic within the sub-forum, the BP Activity is created as expected (seen in the admin screen under Activities), but it doesn’t show up in the BP news feed of my non-admin test user. The other way works, though: if my non-admin user posts a reply to that topic, then this activity shows up in the news feed of my admin user. I need to debug that.