BuddyPress.org

I have the same problem. Every plugins except Buddypress successfully send mails. ( woocommerce, WPForms… ) I tried disabling all plugins, default theme, tried default wp mail, tried smtp trough WP Mail SMTP, Postman…

Anyways. I’ll follow this thread too.

BuddyPress’s Register page is a special kind of page that cannot be edited via the Dashboard. That’s why it’s blank when you view it in the normal way.

To add additional fields to the registration process, go to Dashboard > Users > Profile Fields. Add one for Address and one for Phone Number. Make them required and/or private, if you’d like. As long as they are part of the ‘Base’ profile field group, they will appear as part of the registration process.

When you add BuddyPress’s Register item to your nav menu, it will only show up for logged-out users. If you’d like it to show for *all* users, remove the BuddyPress item, and instead find Register under Pages and add it from there. https://i.imgur.com/Ny7Wj1L.png

That string is not present in BuddyPress itself. It must be coming from the plugin described here: https://buddydev.com/buddypress/force-buddypress-users-to-upload-profile-photo/

Be sure to check for wp-content/plugins/bp-force-profile-photo in your filesystem, and the Plugins screen on both the Dashboard and the Network Admin (assuming you’re running Multisite).

These tabs are hardcoded into the theme template. So you have two options:

1. Override the theme template in your own theme (copy /wp-content/plugins/buddypress/bp-templates/bp-legacy/buddypress/activity/index.php to /wp-content/themes/[your-theme]/buddypress/activity/index.php, open the copied template, and remove the tabs you don’t want.

2. Hide with CSS. Eg

body.activity.directory #activity-friends {
    display: none;
}

Seriously amazing work @peter-hamilton! It looks better than any premium Buddypress/bbPress theme I’ve seen. Great job and can’t wait to see the finished product!

Hm. I have never seen a problem like this before. It sounds like the problem is not really with BuddyPress per se, but instead some sort of database corruption.

Are you able to run mysqlcheck? http://www.thegeekstuff.com/2011/12/mysqlcheck/ A total guess, but it could be that this will clear up some of the problems.

Try this great article:

Como tornar os perfis de membros do buddypress privados

If the users of the site don’t care too much about what it looks like, then I would suggest switching to a theme like Twenty Sixteen. This will move you over to a “template pack” that is more modern and well-supported by the BuddyPress team.

Otherwise, there’s no danger in sticking with the existing theme, as long as it’s working for you. It’s outdated in the sense that it won’t receive any more feature updates from the BP team, but if you’re not using most BP features, this probably won’t bother you or your users 🙂

> Now the problems I see is that when creating a new thread, the thread is created and shown but only the title, the content posted when creating the thread is hidden. All subsequent replies show just fine.

If this is a CSS issue, it’s easily fixed. Look at the page source to see if the content is there. If so, it is probably being hidden by a rogue style, which you could override. If not, it’s a deeper problem that may require some PHP skills to debug.

Oy, this is not a good piece of advice from the Avada support folks. You cannot put PHP into a text widget. I gave you a snippet of PHP with the understanding that it’d have to be added through code somehow.

If you haven’t got the resources to build a proper custom widget (no worries if not, it is a bit cumbersome to do), you may try a plugin like https://wordpress.org/plugins/php-code-widget/. You should be able to paste the text in question into one of those widgets and have it work.

Widget-friendly shortcodes for BP content is a good idea for a future enhancement. I’ve added a comment to an existing ticket we have to track a related idea. https://buddypress.trac.wordpress.org/ticket/7159#comment:2

Very interesting question.

It’s not currently possible to do this through the regular activity API. We’ve hardcoded ASC into the comment query: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-activity/classes/class-bp-activity-activity.php?marks=1510#L1509

I think that it would be a good enhancement request to add something to the query API that allows for these items to be reversed. If you’re interested, I encourage you to open a ticket at https://buddypress.trac.wordpress.org.

In the meantime, here’s a clunky workaround:

add_filter( 'bp_has_activities', function( $has ) {
	global $activities_template;

	foreach ( $activities_template->activities as &$a ) {
		$a->children = array_reverse( $a->children );
	}

	return $has;
} );

This will only affect top-level comments; you’d need something recursive to do deeper levels. And you may want to limit this to front-end queries, or in the main activity directory, or something like that. But it’s a basic technique that should give you a sense of how to solve this in the short term.

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