BuddyPress.org

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()

2) … Also there, there is no way to change things here ? Add the thumbnail on the posts list for example, or separate the “comments” and “posts” tabs,…

“Things” can be changed programmatically. Additionally, BuddyPress does not come standard with “Posts” or “Comment” tabs. The only separation for these items is via the dropdown filter selection for “Posts” or “Comments” located in the Sitewide or User Activity streams which is standard for BuddyPress.

3) OK, really confusing.
And if the displyed name and real name arent the same, how can a user know the real @ he has to use to tag someone ?
BTW, i’ve made some tests and even if i use @displayname or @username, it doesnt send a notification to the user,…

Users typically figure out who is who and for @mentions, only the username is used for notifications. For example, a scenario where there are 2 users with the same displayname which happens to be Apple, however, each has a different username because usernames must be unique. Maybe a visual will help you digest this information:

If you are having issues with notifications, that is a different issue and might be related to some external factor such as a plugin or theme that is interfering with the notification process.

As for Main settings, yes, those available via a UI are limited, however, programmatically, there are plenty via constants, filter hooks and action hooks.

Unfortunately, you’ve applied a band-aid at the Theme level. The next Theme update will remove your band-aid and you will have to apply it again, given the approach you’ve taken.

The bp_loggedin_user_domain( ) function should have returned a URL with a trailing slash, for example:

http://www.url.com/members/username/

Which is why the Theme has it written as:

bp_loggedin_user_domain() . $bp->notifications->slug

Something is causing the trailing slash to be missing, solving for this will be the fix. Maybe a plugin or some custom code is filtering the return value, such that is stripping the trailing slash.

Assuming you are using BuddyPress 14.3.3, see the following URL for the source code:

bp_loggedin_user_domain()

Hi @dreampixel,

Thanks for bringing this to my attention. It looks like some of the notifications are not being deleted when in actuality all should be deleted that are related to the deleted user.

For example:

• new_membership_request <- this is what you initially indicated
• bbp_new_reply <- this what you indicated next
• new_message <- notification for Private Messages

The issue is that the function that deletes notifications in the event of a deleted user does not take into account that some notifications have the user_id of deleted user placed in the secondary_item_id column in the bp_notifications`database table.

Long story shorter, I have a tentative patch that I am testing that will provide a remedy for this bug. I’ll create a ticket for a fix once I’m satisfied with the patch. I’ll keep you updated as to the progress and I’ll try to fit this into the next available release.

Hi Luca! It sounds like you’re building a unique feature with delayed visibility for interactions—cool idea! Let me break this down for you and provide some guidance:

1. User Interactions Visibility Logic
You’re debating between two strategies:

Option 1: Posts become visible after X hours.
Option 2: Posts become visible at the next 8AM local time, but only if it’s X hours after posting.
Implementation Thoughts
Database-level flags: Add a visible_from datetime column to your interaction records (e.g., posts, comments, stars). This way, you calculate when they should become visible at the time of creation.

For Option 1, set visible_from = created_at + X hours.
For Option 2, calculate visible_from as the next 8AM that occurs at least X hours after created_at.
Query filtering: Use this visible_from column in your database queries. For example:

sql
Копировать код
SELECT * FROM interactions WHERE visible_from <= NOW();
This ensures you’re only fetching interactions that should be visible.

Efficient templating: Instead of adding logic in templates, handle this at the query level. Templating frameworks (e.g., Django, React) should just display what is passed to them, avoiding inefficiency in loops.

2. Handling Email Notifications
You want to delay email notifications about interactions while ensuring administrative emails (like password resets) remain instant.

Approach
Separate email queues:
Use a task queue like Celery (Python) or Sidekiq (Ruby) to handle email sending.
Assign different priorities or queues for email types:
High priority: Immediate emails (e.g., password resets).
Delayed priority: Interaction notifications, where tasks are scheduled to run after visible_from.
Notification scheduler:
Add logic to enqueue email notifications for interactions only after they become visible.
For example, enqueue interaction notifications at visible_from time using delayed task execution.
Example: Scheduling Emails
If using Python and Celery:

python
Копировать код
from datetime import timedelta
from celery import shared_task

@shared_task
def send_email(user_email, interaction_id):
# Logic to send the email notification here
pass

# Schedule email when an interaction is created
interaction_time = … # ‘visible_from’ datetime from logic above
send_email.apply_async(
(user_email, interaction_id),
eta=interaction_time
)
3. Additional Considerations
Time zones: If you’re using local time for visibility, store interactions in UTC and calculate visible_from based on the user’s time zone.
Edge cases: Consider scenarios like users editing their posts or comments. Decide if you want to reset the delay or leave the visibility timing as-is.
Testing: Ensure thorough testing, especially for time zone conversions and delays, to prevent unintended visibility or email timing issues.
Summary Workflow
On post creation:
Calculate and store visible_from.
Schedule any delayed notifications for visible_from.
On content fetch:
Query only interactions where visible_from <= NOW().
Use task queues to handle email delays efficiently while prioritizing admin emails.
Let me know if you’d like examples tailored to your tech stack or further clarifications! 😊
You can find more info at our FAQ pages.

Hello @pellepedersen

You aren’t getting notification emails when a new user signs up? Am i understanding it right?

I have the same setup as you. Discovered yesterday that people signing up are not receiving activation emails. Today i discovered I am not being notified when someone signs up.

Did you find out why you aren’t getting any emails of a new user signing up. I would have thought that’s the most minimum of an alert which should work without any hiccups.

Three things:

– I can’t replicate the issue you have.
– user_name is not a valid field, btw. It was deprecated.

Using the followwing payload, I actually get this in BuddyPress 14.0 since you are using + in the user_login, that’s not valid.

Request Payload.

curl -X POST "https://bp-demo.test/wp-json/buddypress/v1/signup/" \
     -d "context=edit" \
     -d "user_email=pratik@testmail.com" \
     -d "user_login=testthe+request+" \
     -d "password=\"']));L)Q542q8dL3" \
     -d "signup_field_data[0][field_id]=1" \
     -d "signup_field_data[0][value]=testthe+request+" \
     -d "state=gggg" \
     -d "country=AZE" \
     -d "postal_code=444444" \
     -d "mobile_phone=555555555"

{
  "code": "bp_rest_signup_validation_failed",
  "data": {
    "status": 500
  },
  "message": "Usernames can contain only letters, numbers, ., -, and @"
}

Here is the BP configuration I have locally, taken from my local site: https://bp-demo.test/wp-admin/site-health.php?tab=debug

version: 14.0.0
active_components: Extended Profiles, Settings, Friend Connections, Private Messages, Activity Streams, Notifications, User Groups, Site Directory, Members, Members Invitations
url_parser: BP Rewrites API
global_community_visibility: anyone
template_pack: BuddyPress Nouveau 14.0.0
! hide-loggedout-adminbar: Yes
! bp-disable-account-deletion: Yes
! bp-disable-avatar-uploads: Yes
! bp-disable-cover-image-uploads: Yes
bp-enable-members-invitations: No
bp-enable-membership-requests: No
! bp-disable-profile-sync: Yes
! bp_restrict_group_creation: Yes
! bp-disable-group-avatar-uploads: Yes
! bp-disable-group-cover-image-uploads: Yes
! bp-disable-group-activity-deletions: Yes
! bp-disable-blogforum-comments: No
_bp_enable_heartbeat_refresh: Yes

you could consider adding a chat facility like Wise Chat perhaps?

Like new posts to user notifications, if there is a lot of blogging.

Streamline the options you make available to users, complexity often puts people off.

Hi @imath
Thanks for the help!
Maybe you can suggest something with this. I want to add a counter of new posts from the activity feed to the custom menu.
I put it in functions.php but didn’t get any results. With my meager knowledge, I did not succeed. I can’t figure out how to add a counter to my custom menu.
P.S I’m not sure that the code itself is workable!

Here on the forum I was offered the following code:

<?php
function bp_update_last_visit() {
if (is_user_logged_in()) {
update_user_meta(get_current_user_id(), 'last_visit', current_time('mysql'));
}
}
add_action('wp_login', 'bp_update_last_visit'); 
add_action('wp', 'bp_update_last_visit'); 
?>
<?php
function bp_get_new_activity_count() {
$last_visited = get_user_meta(get_current_user_id(), 'last_visit', true);
$args = array(
'action' => 'new_post', // Adjust based on the actions you want to count
'since' => $last_visited, // Filter activities since the last visit
);

// Query BuddyPress activity with arguments
$activities = new BP_Activity_Query($args);
return $activities->get_total();
}
?>
        <?php
        function add_activity_notification_count() {
$count = bp_get_new_activity_count();
if ($count > 0) {
echo '<span class="activity-notification-count">' . $count . '</span>';
}
}
add_action('bp_menu', 'add_activity_notification_count');
  ?> 

Hi dvalken

Just to add info:

This issue has also been on my site for four years.
Only affects Android devices, not iPhone or pc/laptop.

When the buddypress drop-down items in the admin bar are clicked (top-right on screen) , for example Activity, Profile, Notifications, Messages, then the first sub-menu item is automatically selected and clicked without any user action. The user is unable to select the second or third sub-menu item.

Default WordPress Twenty Sixteen Theme.
Buddypress 10.6.1