Daily/Weekly digest emails not working

Quick note: I set my group subscription to daily digest. When I added a few activity updates, I checked the meta value for the ‘ass_digest_items’. It just showed this: a:1:{s:3:”dig”;a:0:{}}

It seems that the issue might have something to do with the values not getting into that field. Any thoughts?

Nevermind, I actually figured this one out.

Can you please share the solution? I have the same problem and would love to know how you solved it or what you figured out.

Thanks!

We’re working on the exact same issue — emails not being sent either daily or weekly — would you mind letting us know how you fixed it? Thanks!

Edit: I’m not even seeing the ‘ass_digest_items’ anywhere — where am I supposed to find this metadata?

• This reply was modified 7 years, 9 months ago by daanemanz. Reason: extra info

@kalico @daanemanz Are you running multisite?

‘ass_digest_items’ gets stored in the usermeta table (in a serialized array) for each user_id based on the site and subscriptions for each group.

From what I can remember, the code references ‘ass_digest_items’ as a key value in bp_groups_meta for the site.

We were running multisite with BP multinetwork plugin enabled. Long story short, we found out the BP multinetwork places a prefix (e.g. network_’ . $blog_id . ‘) in front of ‘ass_digest_items’ which caused the any digest item to not show in previews, and of course, not to send.

If you are running BP multinetwork, I’d be more than happy to share the coding update to accommodate for the network prefix.

Please let me know if this helps.

@jasonverdelli thanks for your reply! We’re not running multisite on our install, but we do run a locked down site. From what we’ve gathered, when you disallow search engines from indexing your site, this also influences the cron jobs that run — including the ones for the digests.

Not sure if that’s helpful at all, but that’s all we could find before we decided to not use the digests for the time being ??

Thanks for sharing your input and experiences, @daanemanz and @jasonverdelli.

@jasonverdelli – I am indeed running a multisite. However, I’m not running the multinetwork plugin.

I went looking at the bp_groups_groupsmeta table. I do not have any entries at all for ass_digest_items there, but I do have it in wp_user_meta.

Here’s some more info on my setup, along with a trick I found to get things moving for now.

I am able to append /?sum=1 to the end of my URL and it shows all the digest items waiting to be sent. Also I can trigger the digests with cron (more on that in a sec).

I have two copies of my site — live and dev — running different versions of BP. Neither site is sending out digests. Both sites are running WP Crontrol, so I can see cron events.

The dev version of the site is running BP v2.7.x and it has a cron job called ass_digest_event. I can trigger that cron job to run manually, and it does send out the digests. I’ve been doing that as a stop gap.

The live site is running BP v2.6.3 (because of another plugin conflict that prevents me from upgrading), and there is NO cron job listed for ass_digest_event. However, I just created one to run daily, and triggered it once to run manually. It should fire daily going forward. I can likely do the same for whatever cron runs the weekly digest as well, and for that matter, I can do the same on on v2.7.x by creating a whole new daily cron event for it.

But I’d rather that the plugin do its job. ??

I find it interesting that the two versions of BP are different in this respect, but both have the same problem.

Thanks again for the feedback on this one. Hopefully it will be picked up by the devs soon and get some attention, but I know they are busy with the larger BP community and other projects.

@daanemanz @jasonverdelli – Do you know how to purge the existing digest items?

I want to set up a cron job to run for the weekly digests, but there are some really old items that will be sent out, and that’s going to cause confusion amongst those who receive them.

I would rather just purge the existing/old items, then have the new cron start running normally after that with new items.

I looked through the database, but so far I haven’t found anything obvious.

Thanks for any ideas.

For those of you having trouble setting the digest cronjobs and are not using the BP Multi-Network plugin, have you tried deactivating and reactivating the plugin? This should regenerate the digest cronjobs in WordPress.

—-

I read another post by @kalico saying that their site is using a custom BP_ROOT_BLOG site ID.

Just looked into the GES codebase and saw that there is an issue if you are doing this and when you have network-activated the plugin. If you did this, the cronjobs would be registered on the main site and not the BP site.

For those of you using a custom BP_ROOT_BLOG ID, can you try adding these fixes?
https://github.com/boonebgorges/buddypress-group-email-subscription/compare/9cb5968…ae52414

If you feel uncomfortable doing this, download the latest, bleeding version here:
https://github.com/boonebgorges/buddypress-group-email-subscription/archive/master.zip

Then, go to the GES admin page and try to resave the settings and see if the digest cronjobs are registered correctly on the BP site.

Unless you have a need to network-activate GES, you should only activate GES on the site where you have BuddyPress activated.

• This reply was modified 7 years, 9 months ago by r-a-y.

Hi @r-a-y

Sorry for the long delay here….I have been sidetracked with another site to launch.

I just went ahead and tested your bleeding edge master file (seemed less time consuming than the line-by-line updates, and I saved the original that way).

I deleted the existing digest cron jobs, then activated it only in the root blog subsite, and the cron jobs regenerated. I hope that was an accurate way to test.

Thanks very much for your help with this!