More Privacy Options is a plugin for WPMu that allows blog owners to fine-tune their blog’s privacy settings, expanding on the default privacy settings offered in the WP core. Putting this plugin together with BuddyPress has been problematic, however, because BuddyPress is not built to recognize the new privacy settings defined by MPO. As a result, even private blog posts get put into the public activity feed.
This plugin, BP MPO Activity Filter, does just what the name suggests: it filters BuddyPress activity feeds (wherever bp_has_activities appears) and filters the output based on the privacy settings of the source blogs. For example, if a blog is set to be visible only to logged in members of the community, BP MPO Activity Filter will only display activity items corresponding to that blog (both posts and comments) to users who are logged in. Sitewide administrators will have an unfiltered activity stream.
I borrowed the idea, and a little bit of the code, from this plugin. Because of incompatibilities with the way earlier versions of BP stored activity item data, this plugin will not work properly with installations of BP 1.1.3 or earlier (nor will it work on data created on that version of BP, even if the core software is updated).
BP MPO Activity Filter has been downloaded [downloadstat url=”http://wordpress.org/extend/plugins/bp-mpo-activity-filter/stats/” get=”total” autop=”false”] times. Are you using this plugin? Consider a donation.
Version history
- 1.0 – February 7, 2010
- Initial release
- 1.0.1 – February 22, 2010
- Added code to ensure that plugin is not loaded before BuddyPress is
- Updated readme file to include more information on compatibility with BP < 1.2
Pingback: Teleogistic / New BuddyPress plugin: BP MPO Activity Filter
Hey Boone since you’re unstoppable right now and my rss inbox is going crazy: A few suggestions: I think bp still needs a rocksolid breadrumbs and sitemap plugins 🙂
Boone, Thanks for the plugin. I just installed the it and am getting an error log full of the following. The number listed below varies. Any ideas? the mpo filter is referenced at the end of the line (using BP 1.2, WPMU 2.9.1):
WordPress database error Table ‘xxxxxxx_mu.wp_1627_options’ doesn’t exist for query SELECT * FROM wp_1627_options WHERE option_name = ‘blog_public’ made by require, require_once, include, dynamic_sidebar, call_user_func_array, WP_Widget->display_callback, BP_Blogs_Recent_Posts_Widget->widget, bp_has_activities, apply_filters, call_user_func_array, bp_mpo_activity_filter, get_blog_option
Thanks for this plugin. Much needed. I’m seeing this in my error logs:
PHP Warning: Division by zero in /var/www/html/wp-content/plugins/buddypress/bp-groups/bp-groups-templatetags.php on line 69, referer: http://example.com
I haven’t had a chance to test the plugin properly. Will do on Monday, but wanted to let you know about the error.
Mark, when you say that “the number listed below varies”, do you mean the blog id number? Are you replacing something with those xs in ‘xxxxxx_mu.wp…’ or is that how it shows up in the error log?
Joss, I’d be very surprised if those errors had anything to do with this plugin. The line it makes reference to occurs within the BP_Groups_Template class, which is called by the global variable $groups_template – but that variable is not called anywhere in my plugin. The particular error seems to be that a page number is missing in a listing of sitewide groups. This could be from a group widget, perhaps? Try disabling all BP-related plugins except for BP and see if it’s still happening.
Yes, the blog ID number varies. It’s listed as 1627 in the provided example. The xxxx is just replacing my hosting account/server name. The plugin appears to be working except for ongoing creation of database table errors.
Yes, I think you’re right. The error doesn’t look related. One other thing I’ve noticed (using the default theme for BP 1.2) is that the plugin hides private activity but leave a series of empty lines in the activity stream with ‘Reply (0) Remove Favorite’ to the right side.
The HTML source for a typical line is: http://pastebin.com/m7053fa5d
Mark, the error seems to say that there is no options table for the blogs in question. Is that true? I’m determining blog privacy with get_option( $blog_id, ‘blog_public’ ), which looks for an option with the key ‘blog_public’ in the blog’s option table. If you’re getting errors with different blog ids each time, then it sounds like the table must exist – it’s just that they’re not always being found. Is there any pattern at all among the blogs referenced in the errors? Are they all set to a particular privacy level, for instance?
Joss, glad to hear it’s unrelated. As for the other problem, I thought I’d fixed that with a little trick array_values trick near the end of the plugin, but apparently it’s broken again 🙂 I’ll haven’t checked in 1.2 stable as it’s only been out a few days, so maybe something changed there. In any case, I’ll have a look and update the plugin when I fix it. Thanks for reporting the issue.
Since you seem to approach life as one big problem to be solved, here’s one more and the pattern:
Visit page with ‘recent site wide posts’ widget
4 errors are generated with each use of filter:
“WordPress database error Table ‘dbName_mu.wp_1633_options’ doesn’t exist for query”
Other blog IDs
wp_1634_options
wp_1638_options
wp_1640_options
The option table exists but I looked through my database and I don’t have any blogs with those IDs. Those IDs all appear as Post IDs. All four can be found as Post IDs within 2 different blogs. Just to make things more interesting, the 2 blogs are a (1) Sitewide Tags site and (2) a site using feedwordpress to pull content from the sitewide tags site. I deactivated both of the blogs that contain the referenced Post IDs but that didn’t fix it. There are other post IDs within the Tags and Feedwordpress sites and they are behaving properly.
It looks like this ‘my special problem’ and not plugin specific. Any idea as to how those 4 numbers are getting used as blog IDs when they shouldn’t? As a less then perfect fix, what code I could add to the plugin to tell it to not query those specific ID numbers?
Mark – Yes, I am a problem solver. AWESOME!!!!!!!!!!!!
Your problem is pretty weird. Your note about the post_id vs blog_id makes me think that something is going awry with the setting of a $blog_id variable, but I have a hard time seeing off the top of my head where that might be. Do you still get those errors even when my plugin is turned off? How about when MPO itself is switched off?
When the mpo-filter is disabled the errors are gone. When MPO is off and the filter on, the errors remain.
I need to restate what I said above, even though I think you understood. Options tables exist for all of my blogs but since the numbers referenced in the errors do not match any blog IDs, there are no Options or any other tables for those nonexistent IDs (which is what you’d expect and is overall is a good thing).
Yes, it seems too strange of a coincidence for these numbers randomly be post IDs. Especially since I’m not dealing with probably even 1000 total posts. My highest real blog id is 107. Of note, the filter is identifying real private blog IDs and keeping them from displaying in site wide activity.
I appreciate you keeping this info in the back of your mind.
Hi Mark. OK, I have looked a bit closer at the code and I’m getting a glimpse of what must be happening. I’m using code to switch_to_blog($blog_id), and $blog_id is declared as the primary item_id of the activity. I guess I thought that the item_id for new blog posts was always the blog_id of the blog, but it looks like it’s becoming the post_id for these particular activity items. Not sure why that might be. It’s possible that it has something to do with the fact that they are feedwordpress/sitewide tags blogs – though I admit that I don’t see why this would make a difference.
Would you consider inserting the line print_r($activity); inside the activity loop and pasting the content of one of the problematic items here so that I can take a look at it? Or by email is OK too if you’d rather.
Just a little update to those following this thread: from some email conversations with Mark I’ve come to conclude that it’s not feasible to make the plugin work for versions of BP 1.1.3 and earlier, or with data created in those versions. I’ve updated the readme file and this post to reflect this.
If anyone is interested in modifying the plugin to work with earlier versions, here’s a brief description of the issue. This plugin (BP-MPO) needs to know the blog_id of the blogs associated with activity stream items. Currently that information is the item_id of an activity item, but formerly the item_id of a new blog post/comment was the post/comment id, NOT the blog_id. From what I can tell, there’s no immediately straightforward way to get the blog_id from the information given in one of these older BP activity items, other than to break apart the primary_link, call up an array of all the blogs on the system, and try to match the domain and path of each one (or to break the URL into domain and path and use get_blog_id_from_url).
Boone – thanks for some more great work! I am seeing one issue with this plugin, though (BP 1.2, WPMU 2.9.1). It messes with my widgets in the default theme. I have an RSS widget that disappears, and the links widget resets to blogroll from the link list that I had chosen.
Any ideas?
Hi, just to let people know, dsader has released a new version of his plugin and it’s now hosted on the WordPress repository:
http://wordpress.org/extend/plugins/more-privacy-options/
Your BuddyPress plugin seems to work fine with the new version.
I’m not sure if you are still supporting this plugin, given that the wpmudev version seems to have attempted to integrate the functionality directly into the plugin.
I say “seems” because it is not working for bp 1.2.9. As Joss mentions above, dsader’s version of the plugin used to work in concert with this plugin, but the combo doesn’t seem to work for me anymore (WPMS 3.2.1). I suppose I am posting to inquire as to whether or not you are aware that this isn’t working (perhaps it has been abandoned), or to triage whether I am the only one experiencing this issue.
resolved. Thanks for updating.
Another missing filter is the activity associated with the Group Blog plugin. A blog that is set as private to members, or to admins, still registers a “name posted a blog in the group” item on the activity feed. You get a few lines of what should be a private post showing up on the main feed. Clicking on the link takes takes you to the screen that states you must be a member to read, but the two lines on the activity feed probably shouldn’t appear at all.
I commented out lines 963-1010 of the code in the bp-groupblog/bp-groupblog.php file in the Groupblog plugin, which replaces the normal blog listing on the activity feed with at groupblog update. This makes posts to the groupblog just return a regular activity stream update, which is filtered by the MPO Filter. This also removes the listing within the group that someone has posted on the groupblog, which is a negative to this fix, but does seem to rectify the privacy concerns. If someone has a more elegant fix, I’d love to hear it.