Core notifications and emails when a blog post receives a comment

[henrywright]

Are core and email notifications sent when a blog post is commented on? I certain they are sent when an activity item receives a comment but not sure the same is true for blog posts.

If not, would this feature be good to have in core? I could try writing the code if anyone thinks it would be useful.

Grateful for your thoughts.

[boonebgorges]

Nope, I don't think that this is built into BP (unless you're @-mentioned in them). I assume that we've never really handled this in the past because blog posts are not BP content. But now that we have a more robust notifications component, it's something to consider. If we went this direction, we might want to do some rudimentary checking to make sure that the author isn't already set to get WP-native emails ("email me whenever someone comments on my post").

Unless other devs have an objection, I think you should go ahead and start on a patch. This would be a cool feature.

[r-a-y]

I'm fine with this.

The only thing I can think of at the moment is if we should record notifications for anonymous commenters. If anonymous commenters are allowed, when we decide to reformat notifications to show avatars, we could probably use the user's gravatar. Could cause confusion thinking if the anonymous commenter is an actual member on the site. Just thinking out loud.

This ticket also got me thinking that we'll probably need a "Settings > Notifications" page (similar to "Settings > Email") so users can disable certain screen notifications, but that's a separate enhancement request for a future release :)

[henrywright]

boonebgorges and r-a-y

I've had a stab at putting the basics in place. Please see patch attached.

To do or to think about:

1. How are the notifications handled when a user, post or comment is deleted
2. Multisite
3. Duplicate emails and notifications when an at-mention is used in the comment
4. Rudimentary checking of WP-native emails (suggested by boonebgorges)
5. Anonymous commenters (suggested by r-a-y)

[henrywright]

Had a think about my patch and it might not be the most efficient way of doing it. For example, i'm questioning if bp_blog_post_new_comment_notification is needed when bp_activity_new_comment_notification could be modified with a conditional check to see if it is a blog comment or an activity comment - sort of similar to how bp_activity_at_message_notification checks if the at-mention is happening in a group or in an activity update.

Than all is needed would be:
add_action( 'comment_post', 'bp_activity_new_comment_notification_helper', 10, 2 );

Grateful for any thoughts.

[boonebgorges]

Hey henrywright - Thanks for the patch. Couple thoughts:

• To me, it makes more sense for this to happen in the blogs component. No point in loading it into memory if Blogs is not activated. This'll also take care of the multisite bit.
• I like the motivation behind your suggestion to combine with bp_activity_new_comment_notification_helper(), but I think that the logic required internally would probably be overkill. Though activity comments and blog comments are both called "comments", they're different types of data objects, and the logic for building the content of the activity item would have to be very different. You'd end up with great big if then blocks. Probably makes more sense to keep them separate.
• I really like the bit about adding BP notifications for blog notifications.
• Your 1-5 points above :)

I'll tentatively put this into 2.0. Let's discuss in the upcoming weeks as we set scope for 2.0.

[henry.wright]

Hi boonebgorges

Thanks for your thoughts. Great to hear it might squeeze into 2.0. I think there's quite a lot to chew on in this ticket - more work involved than I originally thought (well at least compared to sending emails and core notifications for private messages for example).

To me, it makes more sense for this to happen in the blogs component. No point in loading it into memory if Blogs is not activated. This'll also take care of the multisite bit.

It does makes far better sense to happen in the blogs component. As you say, this should take care of multisite too.

I like the motivation behind your suggestion to combine with bp_activity_new_comment_notification_helper(), but I think that the logic required internally would probably be overkill. Though activity comments and blog comments are both called "comments", they're different types of data objects, and the logic for building the content of the activity item would have to be very different. You'd end up with great big if then blocks. Probably makes more sense to keep them separate.

Good point, agreed!

I did some further investigation with reference to bullet points 1-5:

How are the notifications handled when a user, post or comment is deleted

We'd also need to think about status transitions of posts and comments such as trashing and de-trashing; published to draft and so on

Multisite

I think this one could be handled by your suggestion to move to the blogs component

Duplicate emails and notifications when an at-mention is used in the comment

Which notification should take precedence?

Rudimentary checking of WP-native emails (suggested by boonebgorges)

wp_notify_postauthor is the function that handles the native emails. It's a pluggable function so can be overridden. Not sure of the BP policy regarding pluggable functions? I've heard they can be dodgy to use. Perhaps this is unfounded?

Anonymous commenters (suggested by r-a-y)

Should anonymous comments generate an email, a core notification, both, or none?

[boonebgorges]

Looks like we won't have anything ready for 2.0. henry.wright, if you're still interested in taking this one up, let's talk about what'd need to happen.

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/