wp_bpges_queued_items Table is Empty

Thanks for the detailed report.

You mentioned that your test group has two members. Are you certain that they are both subscribed with the ‘Daily Digest’ setting? Also check their corresponding rows in wp_bpges_subscriptions.

Are immediate (“All Email”) notifications being sent, or is this problem specific to digests?

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.

Thanks. This helps to narrow it down somewhat.

Check the wp_bpges_queued_items table immediately after posting an item. The newly created activity should create a dig item for each member in the group who’s subscribed at that level – ie, one for user 3 and one for 153. Is this happening?

No, it is not happening. There is no new activity in the wp_bpges_queued_items table after posting to a group.

This helps to narrow it down even further.

You mentioned that you’re testing with a “discussion” item, which I assume means a forum topic/reply created via bbPress. Is that correct? If so, perhaps you can try to see whether other sorts of activity is properly added into the queued_items table. For example, a new activity post (in the “what’s new” box).

Can you confirm that you have the BuddyPress Activity component enabled, and that activity items are being created properly for the group? See either wp_bp_activity (component ‘groups’) or the main page of the group.

Once activity items are created, BPGES uses the logic at https://github.com/boonebgorges/buddypress-group-email-subscription/blob/1971a19d9efb4097d5ace1952c630f38abc58c7d/bp-activity-subscription-functions.php#L108 to decide whether they should be added to the queue. There’s a bunch of places here where something might fail: an activity type is in the ‘ass_block_group_activity_types’ array; the user is not registered long enough on the site; BPGES can’t find the group for whatever reason; the correct subscriptions aren’t being found (though you said that wp_bpges_subscriptions is populated as expected); the bulk_insert() call is failing for some reason. But whatever’s going wrong, it must be somewhere in the scope of this function.

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 1 year ago by michaelimi.

Boone, I have tried everything I can think of to get this to work. Is there a way we can set up a staging site for you to test with? Or what else can we try to get this to work?

Thank you for your help!

Sorry you’re still not able to make this work. It’s possible that there’s something happening specific to BuddyBoss – I’m unsure how their discussion forums work. The best I can do is to point you toward https://github.com/boonebgorges/buddypress-group-email-subscription/blob/1971a19d9efb4097d5ace1952c630f38abc58c7d/bp-activity-subscription-functions.php#L108 to do some further debugging.

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 think I have identified the issue. This function below is the culprit. Specifically the part about

“/** bbPress 2 ****************************************************/ // groan! bbPress 2 hacks! // // when bbPress first records an item into the group activity stream, it is // incomplete as it is first recorded on the ‘wp_insert_post’ action”

/**
 * Block some activity types from being sent / recorded in groups.
 *
 * @since 3.2.2
 */
function ass_default_block_group_activity_types( $retval, $type, $activity ) {

	/*
	 * Do not resend a previous bbPress forum item to the group.
	 *
	 * This can occur when unapproving a forum post and later, reapproving it.
	 * We do this by checking the forum post's '_bbp_activity_id' meta entry.
	 */
	if ( 'bbp_topic_create' === $type || 'bbp_reply_create' === $type ) {
		$prev_activity_id = get_post_meta( $activity->secondary_item_id, '_bbp_activity_id', true );
		if ( ! empty( $prev_activity_id ) ) {
			return false;
		}
	}

	switch( $type ) {
		/** ACTIVITY TYPES TO BLOCK **************************************/

		// we handle these in ass_group_notification_forum_posts()
		case 'new_forum_topic' :
		case 'new_forum_post' :

		// @todo in the future, it might be nice for admins to optionally get this message
		case 'joined_group' :

		// BP handles these notifications on its own.
		case 'group_details_updated' :

		case 'created_group' :
			return false;

			break;

		/** bbPress 2 ****************************************************/

		// groan! bbPress 2 hacks!
		//
		// when bbPress first records an item into the group activity stream, it is
		// incomplete as it is first recorded on the 'wp_insert_post' action
		//
		// it is later updated on the 'bbp_new_reply' / 'bbp_new_topic' action
		//
		// we want to block the first instance, so GES doesn't record or send this
		// incomplete activity item

		// reply
		case 'bbp_reply_create' :

			// to determine if the reply activity item is incomplete, the primary link
			// will be missing the scheme (HTTP) and host (example.com), so our hack does
			// a search for '://' because the site could be using HTTPS.
			if ( strpos( $activity->primary_link, '://' ) === false ) {
				return false;

			// we're okay again!
			} else {
				return $retval;
			}

			break;

		// topic
		case 'bbp_topic_create' :

			// to determine if the topic activity item is incomplete, the primary link
			// will be missing the groups root slug
			if ( strpos( $activity->primary_link, '/' . bp_get_groups_root_slug() . '/' ) === false ) {
				return false;

			// we're okay again!
			} else {
				return $retval;
			}

			break;

		/** ALL OTHER TYPES **********************************************/

		default :
			return $retval;

			break;
	}
}
add_filter( 'ass_block_group_activity_types', 'ass_default_block_group_activity_types', 5, 3 );

I am assuming the BuddyBoss has altered this and is no longer recording to the database like this. This does seem to fix the issue though after commenting out the section related to “case ‘bbp_reply_create’ :” and “case ‘bbp_topic_create’ :”.

One thing to mention is that new topics are not being sent in the daily digest even though the subscriber is set to daily digest. The new topic notifications are being sent immediately. The replies are being sent in the daily digest as expected. Maybe this is a consequence of commenting out the code?

Good sleuthing!

It’s quite possible that something in the BuddyBoss system is causing the primary_link to be set in such a way that the BPGES checks you’ve referenced are triggered incorrectly. More likely, perhaps, is that BuddyBoss has its own way of working around bbPress’s apparently odd behavior of creating its activity items more than once. In any case, a more future-proof way of working around it may be to put something like this into your own plugin or theme:

remove_filter( 'ass_block_group_activity_types', 'ass_default_block_group_activity_types', 5, 3 );

This has the effect of removing some of the other things that ass_default_block_group_activity_types does, but if this causes you problems, you could write your own callback that does just those things.

One thing to mention is that new topics are not being sent in the daily digest even though the subscriber is set to daily digest. The new topic notifications are being sent immediately. The replies are being sent in the daily digest as expected. Maybe this is a consequence of commenting out the code?

Hm, I’m not sure about that. You have confirmed that the entry is not being entered into wp_bpges_queued_items for the user+activity combo in question? If so, check the $add_to_digest_queue logic that begins here: https://github.com/boonebgorges/buddypress-group-email-subscription/blob/1971a19d9efb4097d5ace1952c630f38abc58c7d/bp-activity-subscription-functions.php#L199

Hi. I can confirm I have the same issue.

@michaelimi, did you get any further with this. I am contemplating digging in to the code but don’t want to duplicate.

@boonebgorges, thanks for the pointers.

cheers, Colin

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.

Hi @michaelimi. Thanks for update.

I did some digging and BPGE was broken by the BB Platform 2.5.50 release. Looking thru the Github compare releases log for the releases 2.5.40 and 2.5.50, there is one stand out commit that relates to Group forums and notifications.

https://github.com/buddyboss/buddyboss-platform/commit/5b824e75355224288ea776caa01972b8d0e389b0

This shows changes to how they populate $activity_object->primary_link

I’m going to raise a ticket with BB as they claim to support BPGE as a standard BubbyPress plugin. I imagine if this change has broken BPGE it may also have broken other BBP plugins.

C.

Hi @michaelimi.

I have reported the BPGES compatibility issue to BB and they have passed it on to their second line support.

In the mean time I have fixed up the Group forum topic and reply emails to add back in a subject line and fix the ‘go to discussion’ link in the email.

These notification emails are the main use case for us. I haven’t tested this with the Digest notifications.

-C

// ====================================================================
// BPGES / BBP 2.5.50 compatability fix
// With this filter in place:
// - email notifications sent but email subject and email meta are blank (sender, group, topic name etc)
// - daily and weekly digests continue to work
// - Not tested beyond BPGES stuff
// ====================================================================
add_filter('ass_block_group_activity_types', '__return_true', 20);

// ====================================================================
// BPGES / BBP 2.5.50 compatability fix
// fix the 'Go to the discussion' link in the notification email
// ====================================================================
add_filter( 'bpges_notification_link', 'hws_bpges_notification_link', 999,2);		   
function hws_bpges_notification_link( $link = '', $activity_item = false) 
{
	if ( 'bbp_reply_create' == $activity_item->type ) {
		$link = bbp_get_reply_url( $activity_item->secondary_item_id );
	} elseif ( 'bbp_topic_create' == $activity_item->type ) {
		$link = bbp_get_topic_permalink( $activity_item->secondary_item_id );
	}	
	return $link;
}

// ====================================================================
// BPGES / BBP 2.5.50 compatability fix
// fix the notification email subject 
// This is not quite the same as the 'normal' subject line but it
// is better than just the default [Blog Title].
// ====================================================================
add_filter( 'bpges_notification_subject', 'hws_bpges_notification_subject', 10,2);	   
function hws_bpges_notification_subject( $subject = '', $activity_object = false) 
{
	$reply_id = $activity_object->secondary_item_id;
	$topic_title = bbp_get_reply_topic_title( $reply_id );
	$forum_name = bbp_get_forum_title( bbp_get_reply_forum_id(  $reply_id ) );
	
	if ( 'bbp_reply_create' == $activity_object->type ) 
	{
		$subject = 'New reply to the discussion ' . $topic_title . ' in the forum ' . $forum_name ;
	} 
	elseif ( 'bbp_topic_create' == $activity_object->type ) 
	{
		$subject = 'New discussion ' . $topic_title . ' in the forum ' . $forum_name ;
	}
	return $subject ;
}