michaelimi

We are using Stripe for the payments.

I did not get any further. BuddyBoss has escalated my ticket with them to their advance team. It is related to this ticket but also to another issue where the BuddyBoss > Activity, “View Activity” links are not working and so the content of emails (Tokens) are not working correctly or the reply link is not working.

Thanks, Boone. I edited this function function “ass_group_notification_activity” from bp-activity-subscription-functions.php specifically adding error logging as you can see below.

function ass_group_notification_activity( BP_Activity_Activity $activity ) {
    try {
        $is_group_activity_item = buddypress()->groups->id === $activity->component;

        // Error logging for debugging purposes
        if (!$is_group_activity_item && 'activity_comment' === $activity->type) {
            $root_activity = new BP_Activity_Activity($activity->item_id);
            $is_group_activity_item = buddypress()->groups->id === $root_activity->component;
            if (!$is_group_activity_item) {
                error_log('ass_group_notification_activity: Activity comment not associated with a group.');
            }
        }

        if (!$is_group_activity_item) {
            error_log('ass_group_notification_activity: Not a group activity item.');
            return;
        }

        if (false === apply_filters('ass_block_group_activity_types', true, $activity->type, $activity)) {
            error_log('ass_group_notification_activity: Activity type is blocked.');
            return;
        }

        if (!ass_registered_long_enough($activity->user_id)) {
            error_log('ass_group_notification_activity: User not registered long enough.');
            return;
        }

        $group_id = $activity->item_id;
        if ('activity_comment' === $activity->type) {
            $group_id = bp_get_current_group_id();
        }

        $group = groups_get_group(['group_id' => $group_id]);
        if (!$group->id) {
            error_log('ass_group_notification_activity: No group found with ID: ' . $group_id);
            return;
        }

The error it logged was

        if (false === apply_filters('ass_block_group_activity_types', true, $activity->type, $activity)) {
            error_log('ass_group_notification_activity: Activity type is blocked.');
            return;
        }

So I added this to my child theme functions.php

add_filter('ass_block_group_activity_types', '__return_true', 20);

Once I added this filter to set it to return true emails started working again as well as the daily and weekly digest items started to populate.

I have not located the reason why it is returning false without the filter. Do you have any insight?

I am creating a group and a discussion within the group.

The initial discussion and the replies are loaded into the activity feed

I just posted a reply to a group and discussion that I created by another user and the notification did show up in the notifications section.

No email was sent out though, nor was anything added to the database table wp_bpges_queued_items

• This reply was modified 2 years, 1 month ago by michaelimi.

I am certain that the two members are subscribed to Daily Digest for the group.

The wp_bpges_subscriptions table looks like this

When I subscribe to All Emails to see if immediate emails work, nothing is sent out as well. So the problem looks to be for all emails sent by the plugin.

Ok, so for everyone else’s benefit who hosts with Siteground please know that you MUST turn of NGINX delivery for UAM to work!

I was stuck for a day setting up the .htaccess file on Siteground hosting.
In fact, SiteGround serves the static asset files on top of Nginx to make the website faster. However, one of my .htaccess rules is to protect media files from direct access and it no longer trigger due to NGINX DIRECT DELIVERY.

This is a warning message from SiteGround.

With NGINX Direct Delivery we will serve most of the static resources of your website (images, JS, CSS and others) directly through NGINX to achieve the fastest possible loading time. It works for all kind of applications without additional customisation.

For best results we highly recommend having NGINX Direct Delivery enabled at all times. However, if you need to use custom caching .htaccess rules for your static content you may need to switch it off.

To make my .htaccess rule work as expect, I had to turn off NGINX Direct Delivery option under the speed > caching of SiteGround’s setting.

Make sure to flush the dynamic cache before testing the rule again.