BuddyPress.org

I’m not clear on which/what email that is not being sent. AFAIK, there are 2 emails sent for a successful email address change, for example from the WordPress (WP) backend:

1. Email Change Request <- contained in subject line as sent by WP
2. Email Changed <- contained in subject line as sent by WP – after a successful change of email address

For the BuddyPress (BP) frontend:

1. Verify your new email address <- contained in subject line as sent by BP
2. Email Changed <- contained in subject line as sent by WP – after a successful change of email address

For the BP process, please indicate which of the 2 emails is not being sent.

With BuddyPress 12.x.x or greater, URLs, a.k.a., BuddyPress Directories, is the default configuration (see BuddyPress URLs settings) as opposed to pages. See Navigation menus for additional set-up information.

In the event that you require BP pages, you will have to install and/or activate the BP Classic plugin.

As to shortcodes, there are no built-in (internally defined) shortcodes for BuddyPress.

What WordPress theme are you using? Also, when you are in the wp-admin area, go to Settings > Permalinks and make sure the “Permalink structure” is not set to “Plain”.

What might help is that you include a screenshot of the menus and what a page looks like with no content. For example, the following is a screenshot of a page (with content) when the “Activity” menu item is selected:

Additionally, what WordPress theme are you using?

If you had installed BuddyPress prior to version 12.x.x, e.g. versions 11.x.x and below, then you would have had pages. If you install versions 12.x.x and above, the default will be directories as opposed to pages. If you wish to have pages again, then you need to install and/or activate the BP Classic plugin.

Hi @locker17,

I don’t know the answer to your question (sorry!) But I’m also trying to reorder the members list in various ways, and I’d be interested in knowing what that plugin is that you’re using. Maybe the code in the plugin would yield some interesting ideas.

Unfortunately, if I’m not mistaken, imath left buddypress (and wordpress) sometime back.

Mike

Hi @timostr79,

I’m not sure if this is exactly what you’re asking, but I use the User Switching plugin:

User Switching

Which allows you (as an admin) to switch to being another user, so that you can see the site as they see it. It does have side effects. For example, if you’re tracking when a user was last active, the user will appear to have been logged in when you switched to them. I have a “test user” (with normal user privileges) that I switch to for testing the site.

Hope that helps,

Mike

Hi @rayray23,

Since nobody seems to be replying to this … I’m definitely no expert, but I think it’s possible you might want something like:

if (is_user_logged_in()) {
        $user = wp_get_current_user();
        $username = $user->user_login;

I personally find it hard to search the WP documentation, but there should be information in:

https://developer.wordpress.org/reference/functions

Hope that’s helpful,

Mike

When using the Classic Widget plugin, deleting a widget from a sidebar or footer area will remove the widget from that area. Widgets that can be added are listed under the “Available Widgets” section (left-hand side).

For BuddyPress widgets to appear in the “Available Widgets” section, when using the Classic Widget plugin, you will have to install and/or activate the BP Classic plugin.

The URL provided in the email notification is just to a page that requires access by an appropriate logged-in user. The issue appears to be related to the process that is constructing the redirect URL. The example you provided appears to be mangled for an unknown reason:

https://infosecportal.ru/wp-login.php/?redirect_to=https%3A%2F%2Finfosecportal.ru%2Fpolzovateli%2Fpauls%2Fbp-messages%2F#/conversation/11

The slash that is after wp-login.php seems to be misplaced, additionally, there should be a slash after 11 and then I would expect &bp-auth=1&action=bpnoaccess after that.

The redirect is constructed in the function bp_core_no_access() which can be viewed at the following URL for BP 14.3.4:

https://github.com/buddypress/buddypress/blob/14.3.4/src/bp-core/bp-core-catchuri.php#L328-L405

Typically, $mode is equal to 2 which will then execute the code represented by lines 371 through 381: i.e.:

		case 2:
			if ( ! empty( $redirect ) ) {
				bp_core_redirect(
					add_query_arg(
						array(
							'bp-auth' => 1,
							'action'  => 'bpnoaccess',
						),
						wp_login_url( $redirect )
					)
				);

$redirect should be the URL that is represented in the email notification. The function wp_login_url(), which is a WordPress function, constructs/builds the redirect URL. The function wp_login_url() without arguments should, in your case, return:

https://infosecportal.ru/wp-login.php

The fact that there is a slash after the .php indicates that you should look there for why the slash is present, see the following regarding information on wp_login_url():

wp_login_url()

Hi,

Unofficially, AFAIK, BuddyPress v14.3.4 is compatible with the 6.8 branch of WordPress.

Officially, we (the BP team) are behind with the scheduling of the next release. As to when this will occur is, currently, up in the air. Lastly, thanks for the reminder, I’ll have a chat with one of the BP committers to see if we can get things moving forward.

@flamuren,

Support is provided by volunteers and is subject to when someone has time and/or expertise for any given topic request. Additionally, this is not a Job Board, if you require this type of help then you may want to use the following link to make a request of such type:

WordPress Jobs

Hi,

Your best option is to flag it in the #buddypress channel on Slack or to flag it in this forum (Request & Feedback), given that posting in any of the forums doesn’t automatically flag a post as spam or as requiring moderation.

That said, your post was automatically flagged for moderation due having 3 links (3 or more links will automatically place your post into moderation). As to how long it will take will depend on whether a moderator notices the post or is made aware of such, as you have done.

Last but not least, I edited your initial post such that the links don’t register as links, basically encapsulated the links within the code tag/element. Additionally, I released your Topic from moderation.

Let’s me know if my “final final” guess worked. I had a look at how add_filter works in wordpress and I can’t imagine any other method being correct.

Hi,

In order to select WP pages (as it was prior to BP 12), you will have to install the BP Classic add-on/plugin.

Those are the 21 situations that are installed by BuddyPress. If a situation for password reset had existed it would have had to be installed by, at the momenent, an unknown plugin which then would have made the count 22.

So, at this point, it is still unclear whether an email template and associated situation existed prior to March 25. OK, so let’s try something that might provide some insight as to what may be occurring:

1. In an Activity post, @mention yourself, so that you would receive and email. We need to look at the email header information to see whether that email was sent by BuddyPress or by WP Mail SMTP.
2. Send yourself a test message from WP Mail SMTP (once for HTML and once for plain text), again to check the email header information.

Personally, I only use the built-in emailing capabilities for WordPress related messages and BuddyPress for its related messages. However, I did install WP Mail SMTP (default PHP configuration) just to check how it functions with sending emails.

I will also attempt to install All-In-One Security (AIOS) to see if it is installing the password email template and situation.

In the meantime, I’m interested in knowing the results of the email header information specifically 2 key value pairs:

• Content-Type
• X-Mailer

The above list are the keys and an example for the @mention test would be:

Content-Type: multipart/alternative; boundary="b1=_pryh1yml4xJIzLfYeFcRRVRuhNzbjtZon2KyTKgas"
X-Mailer: PHPMailer 6.9.3 (https://github.com/PHPMailer/PHPMailer)

For WP Mail SMTP the results for the HTML test would be:

Content-Type: text/html; charset=UTF-8
X-Mailer: WPMailSMTP/Mailer/mail 4.4.0

For WP Mail SMTP the results for the plain text would be:

Content-Type: text/plain; charset=UTF-8
X-Mailer: WPMailSMTP/Mailer/mail 4.4.0

What I’m attempting to do here is to fill in the blanks, in my mind/have an historical record, and via the process of elimination attempt to figure out what is preventing password reset emails from being delivered.