Skip to:
Content

bbPress.org

Opened 13 months ago

Last modified 12 months ago

#3338 assigned idea

Wrong check for Buddypress notifications

Reported by: SirLouen Owned by: johnjamesjacoby
Milestone: Under Consideration Priority: low
Severity: minor Version: 2.1
Component: Extend - BuddyPress Keywords: 2nd-opinion
Cc:

Description

Inside includes/extend/buddypress/activity.php

In lines 418 and 552

There is a completely wrong check:

if ( ! bbp_is_site_public() ) {
       return;
}

This doesn't have to be checked. Because the site could perfectly be not indexable (what the coder considered "private" which private and non-indexable are not necessarily synonyms) and the site owner could be willing to have all the activity recording activated.

I can't see a scenario where this is helpful at all.

In fact, I was trying to make BuddyPress Notifications happen and I could not understand whats was going on with my site, until, after hours of reviewing the code, I found this.

It's completely counterintuitive. As a regular user, I would have never discovered this relation by its nature.

Essentially, 9 years ago, not sure why it made sense to create r3398 and bbp_is_site_public but I can't figure out any meaning on this code as I've explained (apart of spending a lot of hours to find what was going on between Buddypress and BBpress). I've seen a lot of threads in the support forums from Buddypress for issues with notifications and I'm sure, that this was the culprit in some scenarios (not always but a good portion of the times).

Just a regression on r3398, so I think a patch is not needed. Meanwhile, I will be using the filter, but I think that an action shall be taken on this issue.

Change History (2)

#1 @johnjamesjacoby
13 months ago

  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Review to Under Consideration
  • Owner set to johnjamesjacoby
  • Status changed from new to assigned
  • Type changed from regression to idea
  • Version changed from 2.6.4 to 2.1

In BuddyPress, Activity Stream content is directly linked to whether a site/blog is public or not.

See:

  • bp_blogs_post_pre_publish()
  • bp_blogs_record_blog()
  • bp_is_new_blog_public filter
  • bp_is_blog_public filter

All of these checks use blog_public to determine whether or not to have correlated activity stream content.

Note also this is only for Activity Streams, not for Notifications. All bbPress is doing here, is preventing forum activity from a private site from being logged and stored in a globally public way to the member's public activity stream.

bbPress continues to notify a member to replies to their topics, through BuddyPress Notifications, no matter what the site status is.

If you'd like to change this behavior, the bbp_is_site_public filter can be overridden and you can un'restrict this behavior for your specific use case.


One plausible alternative is to log this activity using the hide_sitewide flag. 9 years ago, and still to this day, that flag is generally not a trustworthy approach to what is considered relatively nuanced and situational access control.

I'm in favor of leaving this exactly as it is. This still seems correct to me. Not to mention there is literally no other setting in WordPress that can be used to indicate site status or visibility.

#2 @SirLouen
12 months ago

  • Severity changed from normal to minor

The only issue as I stated, is that is not intuitive.
I had to browse a lot of code to find what was going on.
As I've stated, there are multiple topics regarding notifications in the buddypress/bbpress forums which probably are because this behaviour.

Maybe the only alternative, is to implement a specific check to hinder notifications/actions/streams at will under the bbpress or buddypress configuration (Personally I checked for this kind of setup like 10 times over the period I was trying to identify what was going on because I could not understand what was going on).

Note: See TracTickets for help on using tickets.