BuddyPress.org

Thanks. I’ve just installed the combination of rename-wp-login and lh-private-buddypress, and I’m unable to reproduce the problem – after logging in, I’m being redirected to the originally-requested page. It may still be worth a test on your end; if temporarily disabling rename-wp-login fixes the problem, it would at least narrow down what’s going on.

If it were my site, the next thing I’d do is to debug the redirection chain, but I’m unsure how familiar/comfortable you are with debugging PHP functions. Try adding the following settings to your wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

After a few pageloads, WP should have created a file at wp-content/debug.log. Once you’ve confirmed this, drop the following into a bp-custom.php file, and then run through the login redirect process. It’ll dump some info into your debug.log file, which we can use for further debugging.

add_filter( 'wp_redirect', function( $redirect ) {
    error_log( print_r( debug_backtrace(), true ) );
    return $redirect;
} );

Hi @plumbingsuperstore – Oof, sorry to hear about the problems, but glad your hosting provider had a way to roll back.

BuddyPress doesn’t touch user credentials, so it’s highly unlikely that BuddyPress itself would be the cause of your admin creds not working after BP was installed. I’m guessing that either there’s some user error here, or there’s another plugin interfering with the process. To reiterate, logging into WP should be exactly the same before or after the activation of BP.

Regarding the 404 error when activating your account: When you install BuddyPress, it should create pages called Register and Activate. It sounds like this worked for Register (since you were able to register a new account), but didn’t for Activate. If you try this again, take careful note of the URLs you see in your browser when registering, the URL that appears in the activation email, and the URL you see in the browser after clicking the activation link. There could be a clue here.

One final tip: You can stay logged in as an admin in your browser and still test as another user. Open a private browsing window: Firefox https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history, Chrome https://support.google.com/chrome/answer/95464?co=GENIE.Platform%3DDesktop&hl=en, Safari https://www.macworld.com/article/1133941/software-web/safariprivate.html

Hi @ovizii – Changing to a separate theme just because of a single styling issue is a pretty big step. If you’re generally happy with the way your site looks and works, it may be worth putting a bit of time into solving the specific issue, rather than looking for a larger switch.

If you do want to change, BuddyPress now supports a feature called “theme compatibility”, which means that it works well in most WordPress themes – whether or not they have specific support for BuddyPress. A nice place to start is the WP default themes (Twenty Sixteen, etc), some of which are particularly well suited to running a BuddyPress site.

Group descriptions are filtered at the time of saving, via wp_filter_kses(), and at the time of display using bp_groups_filter_kses(). https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-groups/bp-groups-filters.php#L35

It seems like a bug that we do different things at the time of save vs the time of display, but there you have it.

I’d suggest removing the groups_group_description_before_save filter, replacing with bp_groups_filter_kses, and then filtering bp_groups_filter_kses to add allowed tags (as @r-a-y describes above). https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-groups/bp-groups-filters.php?marks=117#L87

@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 😀