Stable(ish) release of BuddyPress Group Email Subscription (with digests!)
The front-end is beautiful and AJAXy, thanks to Deryk’s hard work. And I added in weekly and daily digest functionality, so that users can determine whether they want to receive updates from any given group immediately, in a daily summary, or in a weekly summary.
At the moment the plugin lives on my website.
Sounds very interesting, this one passed me by but digests of activity sounds very sophisticated and grown up I’ll test this when I’m allowed 2 mins breather.
Out of interest how does this play with the existing email notifications in a members account area, guess it’s up to them to ensure they don’t receive more than they wish.
Right now there aren’t any global settings for group activity notifications. Individuals have to select their subscription level on a group by group basis. The default for group members is in turn determined by the group admin. Not an ideal solution – I would like to have an option for individuals to override specific settings with something on Settings > Notifications – but maybe that’ll come in another version
I was thinking more along the lines of members/joepublic/settings/notifications as there obviously is already a series of email notifications all set to on by default and including a set of group activity notifications.
My worry is that general users run scared when/if they get too confused by settings, in an ideal world there needs to be one page to rule all notifications for a member, one single point of interaction where they can configure everything site wide.
Yeah, I agree with you. At the very least, there should be something at member Settings > Notifications that sets the default for people’s group email notifications, and then if they want to fine tune them from the defaults they should be able to do that. The way that the interface works right now, it’s very unobtrusive, so I imagine that people who don’t really care about fine-tuning won’t even notice.
Just downloaded and had a quick glance, this looks excellent and extremely useful, the three of you should be commended, I don’t see any real issues for users, yes there will be those that simply don’t get having email notifications in various places but then they are the ones who tend to reply to NOREPLY email notifications and drive me up the wall as they drop into my email box.
How stable is this? Can’t test it in anger right at the minute, but tempted to test it in the wild on the production site??
One minor thing you have broken the forum table by adding the follow button/ extra td as it’s not accounted for in the th row or what ought to be the th row.
The functionality is very stable. My main concern would be server load – I haven’t done anything to stagger digest emails, for instance, so it might cause problems on large installations. I plan to fix this in the future.
Thanks for the catch with the td. I’ll get that fixed this afternoon.
Somewhat difficult to test for, if it were activated for buddypress.org it might be a valid test of a fairly busy site, would Andy be prepared to let you test and crash their server?
Hey all, I’ve removed the *beta status* warning. so hopefully people will start adopting it en masse. @r-a-y I think your email throttling makes sense however what will happen if the script runs for a very long time, won’t it time out eventually? I built this to run on a site with about 8000+ users, so this will be a concern of mine.
@hnla we’ve added a trac request for the hook in the topic.php table header. it should be out with BP 1.2.4.
one more thing. This plugin does add two new things to the user’s general email notifications settings page. The ability to get emails of replies to topics you start and replies to topics you comment on. they are both on by default (like in facebook). I figured these things should be general for the whole site, but that you should be able to control your email subscription for each group – just like google groups. ciao amigos.
Though I hope not all your 8000+ users will enable digests
Just wanted to say that the plugin looks and functions fantastic! I got to do more tests, but it’s a definite must-have!
@r-a-y curious what would happen if you had 8000 + people who had enabled digest. I guess this would completely slow down your site and create a lot of bandwidth expense? So this kind of plug-in should only be used on smaller installs, not super big ones I guess huh?
It was my intention to upload to the production site this morning but had wanted to run as a limited trial so to that end I set about creating an array of allowed_users and was going to try trapping the final add_action? of the plugin with (in_array(“$this_user”, $allowed_users): but crashed and burned trying to get to user id $bp->loggedin_user->id not suitable in the circs. Any idea how it might be achieved?
Not sure if this is a viable notion but was extrapolating the above idea to perhaps a blacklist/whitelist approach in the backend; something like radio control text = ‘Allow selected members only (testing purposes)’ input control for comma separated list of user id’s allowed to see plugin. Second radio control text =’ Allow all members – except those member id’s entered in box’ input control for optional id’s of those denied access to plugin, left blank == ‘allow all’
Not sure that requiring to be able to blacklist users is all that necessary but an ability to run the plugin in a limited trial manner could be?
@hnla Funny you should mention that. I want to do some limited beta testing on my production site before rolling it out to all my users. That’ll require doing exactly what youve mentioned: setting up an array of whitelisted users, and then putting some of the add_actions inside of conditionals so that they’re only shown to those on the whitelist. Now that i know I’m not the only person interested in this kind of thing, I will either update the plugin itself to allow for that sort of whitelisting, or I will post my modified version on my blog or something.
I guess ideally it would be neat to have as a backend option highlighted as a means of testing for a limited number of people. I’m annoyed as I was almost there but simply couldn’t work out how to get to the user ID from within the plugin files
You want to send me what you have and I can have a look at it? Maybe it’d save us both some time.
Can do but it was nothing more than a very crude attempt at hardcoding directly to the plugin not rocket science, I set up a simple array of ids then attempted to create a variable from $bp->loggedin_user->id to use in an in_array() it works in theory but can’t get user_id for love nor money.
Tested with hardcoded value and theory works as shown in :
As you can see was only to quickly facilitate selective members only to receive the plugin views
I’ve got some beta tester white list code already done but for a different thing, not this plugin. It consists of an admin panel where you enter the white listed user names. then simple code to pass on the important parts if the user is not white listed. The admin portion could be used for this, but the front end needs to be written from scratch. maybe it could just remove all the action. or unload the plugin. maybe not what you’re looking for, but let me know if it is.
So do people have opinions on how this plugin would be on a set up that had 5000 subscriptions or more? Would it create massive load on the system and slow things down tremendously? Planning for the future here, is it a good idea to use this plugin if you expect to have a serious amount, many thousands of subscriptions, of usage?
@Dwenaus @boonebgorges That sounds like it’s halfway there, can admin panel simply pass back an array of those white listed usernames or ids? Having got my brain into gear I have arrived at this hardcoded example that simply checks to see if the user ID is in the array before allowing the bp-activity-subscription-main.php page to parse so basically wrap all of the page code in one conditional. I have tested this in as many ways I can think of and it seems ok, but I don’t claim to fully grok the api yet and therefore that there aren’t consequences I have not realised might occur.
This is what I am using:
@hnla That’s a good start, but it means that the plugin’s notifications will only kick in when activity items/posts are posted by users who are on the whitelist. In other words, if Deryk is on the whitelist and I’m not, then even if Deryk is subscribed to all updates from a group that we’re both a part of, he will not receive notifications of my items, because the plugin isn’t firing when I post.
The strategy has to be to find the hooks for the UI and put *those* inside of the whitelist check. I hope to get to this this weekend; when I do I’ll post something in the forums.
Knew there would be something
However in referring to notifications I take that not to mean digests? With digests are they not simply a round up of all events that have occurred in the chosen group? If I’m the only one seeing the plugin would I not still receive a roundup on a weekly/monthly basis regardless? or do I still not grasp the plugin flow(more than likely)
As I have set things up it would still be an interesting test to receive the digests, too some degree it’s the digests I’m interested in seeing in a real world scenario.
With this plugin, digests and immediate notifications use the same logic. When an activity item is saved, a plugin function runs that checks to see whether each member of the group should receive a notification (either immediate or digest). If they receive an immediate notification, it is sent with wp_mail. If it’s a digest notification, the activity id is saved to an array in the usermeta table. When digests run, each subscribed user has this usermeta array checked, and the plugin uses bp_activity_get_specific to call up only those activity items when building the digest.
If the plugin isn’t running when an activity item is saved (and it won’t be if the user isn’t on the whitelist), the logic above never happens.
You must be logged in to reply to this topic.