[buddypress-trac] [BuddyPress Trac] #4831: BP bases site data/activity entries on WP search engine instructions

buddypress-trac noreply at wordpress.org
Thu Mar 22 17:52:35 UTC 2018


#4831: BP bases site data/activity entries on WP search engine instructions
--------------------------+----------------------
 Reporter:  hnla          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Up Next
Component:  Blogs         |     Version:
 Severity:  minor         |  Resolution:
 Keywords:                |
--------------------------+----------------------
Changes (by Boone Gorges):

 * component:  Core => Blogs
 * milestone:  Awaiting Contributions => Up Next


Comment:

 Going to bring this one back to life.

 It's probably fine to use `blog_public` to determine the *default*
 behavior. See #1226, #6274. However, it's not currently possible to filter
 this in a fine-grained way. I'd suggest a few layers of fixes:

 1. All instances of the `bp_is_blog_public` filter should receive the blog
 ID as a parameter. Things get tricky with `switch_to_blog()` in multisite,
 and it'd be much easier to reason about what's happening if we had the
 blog ID to work with. This might be best if we moved it to a centralized
 `bp_is_blog_public()` function.

 2. We should un-hardcode the `0 === (int)` checks. A number of plugins
 extend the `blog_public` setting by adding additional potential values. A
 more sensible default check might be `1 !== (int)`.

 3. That said, I think we can go further, by abstracting the specific
 `blog_public` checks in such a way that they can be filtered in a targeted
 way. For example, instead of the hardcoded check here
 https://buddypress.trac.wordpress.org/browser/tags/2.9.3/src/bp-
 blogs/classes/class-bp-blogs-component.php?marks=98#L86, perhaps we'd have
 something like this:

 {{{
 if ( apply_filters( 'bp_blogs_record_activity_for_site',
 bp_is_blog_public( $blog_id ), $blog_id ) ) {
 }}}

 This way, you could filter `bp_is_blog_public`, or you could do finer-
 grained filtering (as when you *want* activity items to be recorded, but
 you want them to be recognized as non-public when determining
 `hide_sitewide`).

 Any thoughts or objections to this proposal?

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4831#comment:10>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list