BuddyPress.org

@scribit – Thanks for following up. We are getting closer 🙂

Do you have any idea why the home element has the selected class? Does this mean that, when you view the group nav tabs, both Home and Selected have the “current” styling? BuddyPress doesn’t do this out of the box, so I wonder if perhaps there’s something in your theme that’s causing it to happen. Figuring out what’s causing that extra selected class, and disabling it, would probably fix the problem you’ve described.

It is also the case that this JavaScript is quite fragile. I wonder if we could use the body class or something like that as a more reliable way of deterimining which tab we’re looking at. On the other hand, the JS for the new, upcoming template packs (bp-nouveau) is totally different here, so maybe it’s not worth fixing.

Hi @Sander – Thanks for reporting this. It looks like a legitimate bug. I’ve opened a ticket to track it: https://buddypress.trac.wordpress.org/ticket/7631

While we try to figure out a way to make this work better, you can work around the issue by disabling autolink for the field in question. Dashboard > Users > Profile Fields > Edit, and look for the Autolink metabox at the right.

Thanks for the report, @onedevstudios. This sounds like it’s probably a bug. Could you please open a ticket at https://buddypress.trac.wordpress.org with detailed instructions to reproduce? Thanks!

I’m unable to test with the proprietary Magnum theme, but with the free version of Optimizer, I’m unable to reproduce the problem. Group member searches are working as expected: https://postimg.org/image/axag5nsjr/

Here’s the relevant part of BP’s JavaScript: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-templates/bp-legacy/js/buddypress.js?marks=863#L848 The first thing to check is that your theme is actually requiring buddypress.js (or buddypress.min.js) out of the buddypress theme directory; if not, it’s possible you’re running an out-of-date version bundled with a theme or something. Then, you may need to deminimize (or set define( 'SCRIPT_DEBUG', true );) to debug. Then, check to see whether this bit of script is actually able to find the search_terms element. It’s possible that your theme, or some other plugin, is modifying the markup so that the selectors or the element hierarchy has changed.

Hi Naomi – Thanks for the additional details.

I’m afraid I still don’t understand what you mean by “the comment input box” and “the reply area”. Here’s what the activity commenting area looks like on Twenty Sixteen: https://postimg.org/image/yzra0j1h3/ I assume that “the comment input box” is the field at the bottom, just above the ‘post’ and ‘cancel’ buttons. But I’m unsure what in this screenshot represents “the reply area”, and I don’t see any overlap at a glance. If possible, perhaps you could upload a screenshot to a third-party service like https://postimg.org/ and drop the URL here, so that we could better understand the display problem.

The problem I am currently experiencing is that each unique user can make multiple comments on a single post. They should only have the capability to make 1 comment to each post.

And when a user makes a second comment (which they are not allowed to do) that’s when the malfunction occurs and the input box overlaps the reply box.

I’m unclear on what’s happening here. You say that users “are not allowed to” leave a second comment on a post, but I guess what you mean is that you don’t *want* them to be able to do it?

I don’t know of a ready-made plugin that would allow you to limit commenting in the way you’ve described. It would probably be possible to write a small bit of code that would make it work, but I’d need a clearer understanding of what you’re trying to accomplish. If I understand https://buddypress.org/support/topic/how-do-i-make-the-comment-button-read-only-in-the-activity-stream/#post-269197 correctly, you mean that users ought to be able to leave a single *top-level* reply to a given activity item, but they should be able to leave as many replies-to-comments as they want. Is that correct?

I don’t have access to the proprietary ARMember plugin, so I can’t say anything about that.

Here’s one way to show arbitrary content in a BP user’s profile header:

add_action( 'bp_before_member_header_meta', function() {
	$user_id = bp_displayed_user_id();
	echo 'Here is the badge for user ' . $user_id;
} );

You’ll need to use the $user_id to fetch the ARMember badge and display it.

See https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-templates/bp-legacy/buddypress/members/single/member-header.php for other hooks you could use instead of bp_before_member_header_meta.

It looks, at a glance, like the LH Private BuddyPress plugin ought to be doing what you’re asking for. https://plugins.trac.wordpress.org/browser/lh-private-buddypress/trunk/lh-private-buddypress.php#L101

If it’s not working, it’s either because of an error in the plugin logic, or because something on your server or WP setup is interfering with the redirect_to parameter.

Can you share the format of the URL at various points of the process? For example, when visiting example.com/groups/my-private-group as a logged-out user, you should be redirected to:

example.com/wp-login.php?redirect_to=/groups/my-private-group

If, after login, you’re being redirected back to wp-login.php, what is the format of the URL then?

What is the URL format of your BP/WP installation? Are you installed at the top level of a domain example.com or in a subdirectory example.com/buddypress/?

Looking more closely at your styles, the problem might be the width of your #item-meta. Remove the margin-top declaration you entered before, and try this instead:

#buddypress div#item-header div#item-meta {
    width: 200px;
}

Your next step is to start getting familiar with CSS 😀 https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduction_to_CSS

@mbfit If by “unsearchable” you mean that they don’t show up in the directory anymore, then the problem is probably that the plugin deleted the ‘last_activity’ activity items for each user. As such, BP doesn’t show them as active users.

If you retained a backup before you ran the delete process, then you should restore the last_activity items from it. If not, you can run a script that will set last_activity for all users that don’t have it set – though note carefully that it won’t really be *accurate*.

function bbg_set_last_activity() {
    global $wpdb;
    $user_ids = $wpdb->get_col( "SELECT ID FROM {$wpdb->users}" );
    foreach ( $user_ids as $user_id ) {
        if ( bp_get_user_last_activity( $user_id ) ) {
            continue;
        }

        bp_update_user_last_activity( $user_id );
    }
}

As to your original question, there is no single UI or command you can run to delete activity items based on date. wp-cli-buddypress would be part of a good solution, but it would take additional scripting to delete based on date range. If you have some familiarity with bash scripting or PHP scripting, I will point you in the right direction, but I don’t want to just give you stuff to copy and paste, because deleting stuff is dangerous 😀

Don’t abandon the Groups functionality or BuddyPress over this small display issue! With a plugin like this https://wordpress.org/plugins/simple-custom-css/, it is trivial to add the CSS that I gave above.

Building a child theme is more complex, and is something you should learn down the road if you plan to make extensive customizations. But if you just need to make a small change like what I’ve suggested, then a plugin like https://wordpress.org/plugins/simple-custom-css/ is more than enough.

Not what you are serching for but plugin BuddyPress bulk delete can delete all activity.

You can use wp-cli-buddypress to delete the activities from the command line: https://github.com/buddypress/wp-cli-buddypress

Where do I upload my theme to on BuddyPress?

Thanks for the link. It does appear that the margin-top property is the culprit.

Here is the CSS that should fix it:

body.single-item.groups #buddypress div#item-header #item-header-cover-image #item-header-content, body.single-item.groups #buddypress div#item-header #item-header-cover-image #item-actions {
    margin-top: 0px;
}

I don’t recommend that you make the change directly to your themes/parabola/style.css stylesheet, as it will be overridden on the next update. I suggest building a child theme. But you could also use a custom CSS plugin, or the Custom CSS tools in Jetpack.

If your theme uses bp-legacy theme templates, then the styles for the Who’s Online widget are in buddypress/bp-templates/bp-legacy/css/buddypress.css.

https://postimg.org/image/sl03lqwff/

BuddyPress does have a lot of files, but it’s organized according to pretty specific principles, and I don’t think it qualifies as “messy”. In any case, for the purposes of CSS, you can always use your browser inspector (see image above) to locate styles.

Ah yes, thanks for that.

It looks like your theme is loading scripts from BuddyPress, but is using an old path for these scripts. (BP changed the paths a couple versions ago. See https://buddypress.trac.wordpress.org/changeset/11009.) Look in your theme – probably in functions.php – to see how it’s loading the cookie, caret, and atwho scripts. Then update the paths as needed (I think you can just add /vendor/).