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 😀