@justbishop Have you tried https://buddypress.org/community/groups/buddypress-block-activity-stream-types/home/
..but it seems the page where it explains how to adjust for granular level blocking is not working…
Yes, but that blocks it from even being recorded to the DB, which is messing with my main page “featured” post functionality. I need blog posts from the main site to be hidden from everywhere, but not completely gone, KWIM? I figure that there MUST be something that can be done on the template level to just not display them.
Bump. I can find a few bucks to Paypal to someone willing to help me. I’m desperate.
Stuff I’ve tried that either seemed to do absolutely nothing, or make the activity stream stop loading altogether:
“
“
“
There have been more, but I can’t remember all of them 
There is something that you can do, though it’ll mess up activity pagination (which, in the case of AJAX loading, means that the number of activity items loaded when you click “load more” will not always be the same number). It involves filtering bp_has_activities, looping through $activities_template->activities, and removing those items that are new blog posts from your blog.
Here’s an example of the technique, used to remove self-replies: https://buddypress.org/community/groups/requests-feedback/forum/topic/couple-thoughts/?topic_page=2&num=15#post-112100
Thank you for the suggestion, I will take a look after I put my daughter down to nap! It’s more than I had to go on thus far 
Tried adding this to my bp-custom.php, but it didn’t seem to do anything:
http://pastebin.com/ACH039ZW
What do you expect it to do? The point of that specific code, as discussed in the accompanying thread, is to remove individual activity items that correspond to comments on one’s own top-level activity items.
Oh, sorry, I thought that if I modified the parts referring to comments to specify blog posts instead, it would compare them to the blog id of ‘1’ and not display those (`if ( $parent->blog_id !== 1 )` ?). I’m kind of just taking shots in the dark on this and trying desperately to learn something in the process.
To be honest, I’m not even sure I put that code in the correct file, much less what it’s supposed to do just by looking at it 
Have been digging around in core…could something be done with this:
`if ( !empty( $bp->displayed_user->id ) )
$user_id = $bp->displayed_user->id;`
Possibly along the lines of:
`if ( !( $bp->displayed_blog->id ) )
$blog_id = $bp->displayed_blog->id;`
Not sure where/how to implement something like that, but figured it wouldn’t hurt to keep trying to figure it out.
@justbishop I don’t understand what you mean by “it will not save to the DB”? That plugin will help you block one of the duplicates, meaning one of them *will* still be recorded.
You have all your SWT’s post going into the main site, I would think to block main id 1 in your situation. This is what I found still works with the plugin i mentioned. Add to bp-custom.
`//if php is older then change $a to &$a
function my_block_activity_type_blog_id_before_save_1( $type, $a ) {
global $bp;
if ( $a->id )
return $type;
//key on the blog types (even for comments posted to that blog)
if ( $a->type == ‘new_blog_post’ || $a->type == ‘new_blog_comment’ ) {
//item_id is the blog_id in this context
//could add more blog_ids here as well or even parlay into switch_to_blog to block categories, etc
if ( $a->item_id == 1) {
$a->type = null;
return null;
}
}
return $type;
}
add_filter(‘bp_activity_type_before_save’, ‘my_block_activity_type_blog_id_before_save_1’, 9999, 2);
`
I’m a bit confused about this whole thing. BuddyPress is supposed to block SWT posts out of the box: https://buddypress.trac.wordpress.org/browser/trunk/bp-blogs/bp-blogs-functions.php#L163 If it’s not working, then there’s a bug in BP.
@boonebgorges, interesting! I don’t recall ever having this issue before, but I also can’t put my finger on the moment it started happening, either. I did check my copy of bp-blogs/bp-blogs-functions.php, and I DO have that piece of code, so I’m back at square 1 not knowing what the problem is. At least now I know that I’m trying to fix something that’s broken, rather than create a new behavior.
@nahummadrid, yes, one is still recorded, but for some reason, the fact that the other one ISN’T recorded is messing with the “featured” posts area on my index page. The posts given the “featured” designation while the block activity types plugin is activated are not displayed in the featured area as they should be. In fact, it’s as if the page tries to load with one of the posts “featured” while the plugin was turned on, but can’t get past the heading of “featured” (i.e. none of the other page content, sidebar, or footer load). The plugin DOES fix my activity stream problem, but it creates a completely new one in this regard, so I gave up on it.
I’ve done so many mods on my bp-custom.php and functions.php that I don’t even remember how half of them work. Could it be something in there?
bp-custom.php: http://pastebin.com/9NBk5wdw
functions.php: http://pastebin.com/dhxXpdA0
It’s possible that SWT was updated so that the settings key is different. Can you check your database to see if you have an item in wp_options with the name ‘tags_blog_id’?
On searching the db, I do not seem to have that.
Could you open a ticket on trac.buddypress.org pointing to the line that I linked above? I’ll have to install SWT and see how they changed it.
Not sure if I did it correctly, but I tried!
Is this something that I can help with? I have pretty meager knowledge of PHP, but am always up for learning through doing (though I generally need hand holding). If not, what is the next step in the process? Am I waiting for a patch or update to BP and/or the SWT plugin?
Sorry, I have a million things on my plate.
Look through SWT and see how they are storing the tags blog id. Then change BP so that it looks for that piece of sitemeta.
OK, just had a look at the file, and am seriously overwhelmed. I just do not know enough about PHP to figure out what portion of the code I even need to be focusing on.
Is there anyone else willing to help guide me a bit more? This is a serious issue for my site, and I really can’t move forward without fixing it.
Search the SWT for update_sitemeta or get_sitemeta. That will give you a start. I will take a look myself when I get a chance.
Oops – make that update_site_option and get_site_option. Might be worth pinging @wpmuguru about this as well.
Thanks, I really do appreciate you taking the time. I wish I could do more of this type of thing for myself, but I’m afraid that I don’t have the luxury of just sitting and straight learning PHP.
Searched the file for both get_sitemeta and update_sitemeta and got no hits. Will your mention of @wpmuguru send them a notification? Because I don’t think BP is letting me post anything to anyone’s wall right now.
STOP THE PRESSES! I decided to give the block activity stream types plugin another try in my desperation, and it might actually be working WITHOUT messing with the custom post query on my index page that pulls featured posts for display! Still have more testing to do, but all I did was remove the `do_action( ‘bp_before_blog_post’ );` and `do_action( ‘bp_after_blog_post’ );` from around my featured post query, and voila, it loaded a post I marked as featured AFTER activating the block type plugin, and didn’t create a double entry about the editing of the post in my activity stream!
I know it’s not a REAL fix, but if it gets the job done, I’ll take it…
