[@boonebgorges Keymaster 16 years, 8 months ago]

Hi Ray,

Here’s what I think is going on. When you create a new topic, bbPress has to go to the BP tables to find out who’s in the topic’s group and then subscribe them to the new topic. It looks like I wrote the code with the assumption that your BP db is accessible by the same mysql user as your bbPress db. I guess that’s probably not the case in some situations. That could be the problem.

On the other hand, the fact that your error says “using password: NO” suggests that no password is being sent at all, i.e. that $bb->user_bbdb_password is coming up blank. I’m not sure what that’s about.

In either case, a quick workaround is to hardcode your bp mysql db username/pw into the plugin. In

$con = mysql_connect(“localhost”,$bb->user_bbdb_user,$bb->user_bbdb_password);

replace $bb->user_bbdb_user with the user and …password with the pw.

Hope that works.

[@boonebgorges Keymaster 16 years, 8 months ago]

I really need bbattachments for my BP community, and I’ve already started work on porting it over to BuddyPress. There are a few hurdles to overcome, but I don’t think it will take too much longer. I’ll post more when I’ve got something for others to test.

Tore, you can feel free to send me that $100 anytime

[@boonebgorges Keymaster 16 years, 8 months ago]

@r-a-y – Two great ideas. Next time I push out an update I will implement both. Maybe an admin option with checkboxes for where you want the subscribed/not-subscribed messages to appear (on the group home page or on the group forum index page or both). I might get to this next week – earlier if I find bugs and need to update anyway

@Erich73 https://buddypress.org/about/roadmap/ says it’s coming in v1.3 core. That might not be for a while, though.

[@boonebgorges Keymaster 16 years, 8 months ago]

Wow, I’m fast. New version of Group Forum Subscription that works with BP 1.1: https://wordpress.org/extend/plugins/group-forum-subscription-for-buddypress/installation/

[@boonebgorges Keymaster 16 years, 8 months ago]

Wow, Westpointer, we had the same idea at the same time. https://buddypress.org/forums/topic/group-forum-subscription

My version allows a bit more user control (opting out of specific discussions or entire groups) by using bbPress’s native Favorites function. I wonder if there’s some way you and I can combine forces

[@boonebgorges Keymaster 16 years, 9 months ago]

Hi cozzie. I’m not sure whether you’re still interested in a solution to this, but I just wrote a plugin that lets you select what you want the Groups and Members widgets’ default views to be. You can get it here http://dev.commons.gc.cuny.edu/2009/09/07/new-buddypress-plugin-enhanced-buddypress-widgets/

[@boonebgorges Keymaster 16 years, 9 months ago]

Hi Modemlooper – not sure whether you’re still interested in this, but I was looking to make a similar change (I wanted recently active members to show by default). I wrote a plugin to make it happen: http://dev.commons.gc.cuny.edu/2009/09/07/new-buddypress-plugin-enhanced-buddypress-widgets/. Hope it helps.

[@boonebgorges Keymaster 16 years, 10 months ago]

You’ve got to replace the whole line. (Or just back out !(int) at the beginning of the if statement and replace it with 1 >, which amounts to the same thing.) Let me know how it works.

[@boonebgorges Keymaster 16 years, 10 months ago]

@Flynn – Glad you got the single sign-on working! The visual integration really just came from an excessive amount of CSS elbow grease. I’m a bit embarrassed to say that our solution for sitewide navigation isn’t as elegant as yours – the WP nav is hardcoded into the MediaWiki template. We were in a rush to get the thing together (and frustrated with the less-than-ideal theming structure of MW!) and it never occurred to us. I’ll definitely look into using includes to make this work.

As for the activity plugin – it’s hard to know from just the blank screen just what’s wrong. If you’re getting the problem even without saving pages, then it’s unlikely that it’s a problem with the code (since it is only hooked when a wiki page save is complete). A couple possibilities:

• You might want to take a look to make sure that there is a close ?> in the MW extension. I had to leave it out of the MW documentation page because of the way the MW knowledgebase renders PHP (I guess?). If MW isn’t detecting an end to the extension, it could cause a panic.
• Where did you place the require_once line in your LocalSettings.php? My system was finicky; I only got the plugin to activate correctly when I made it the second to last require_once in the config file (just before the WP redirection extension code). So you might try playing around with the location of this file.
• Make sure as well that the line in LocalSettings.php is pointing to the right location – [MW-directory]/extensions/buddypress-activity/buddypress-activity.php, or whatever alternative location you’ve chosen on your system.

Hope that helps at least a little!

@Hempsworth – It’s funny that you mention the class=timesince – I must have spent three hours trying to get that to work one way or the other. The problem is that the timesince span tags are added in the individual BP components (groups, blogs, wire, etc). To get wiki functions to work the same way I would have to abandon the quick-n-dirty activity hack that I employed and actually build entire wiki BP classes. Maybe one day! In the meantime, you might try this even quicker-n-dirtier hack that I mention in the Usage section of the extension page. The preg_replace code I give there goes in BuddyPress core, around line 226 and 230 (ish) of [wp-install-directory]/wp-content/plugins/buddypress/bp-activity/bp-activity-templatetags.php. This hack will only apply to new wiki activity – not the stuff that you’ve already posted – so make sure to make a new wiki edit to test.

[@boonebgorges Keymaster 16 years, 11 months ago]

Hi r-a-y,

Glad the filter is useful to you!

I think the answer to your question is yes, John Smith’s profile would come up in that kind of scenario. The links that are created in BP profiles are merely full-text searches on all BP profiles (this is the link behavior out of the box, and my filters do not change this). Even if the name “Smith” in John’s profile doesn’t link to http://[your-buddypress-url]/members/?s=Smith, that search URL will still be live and accessible from the regular BP search box.

I haven’t looked into the details, but it should be possible to build a plugin that limits search in different ways. You might, for instance, search all profile fields except those that have been tagged as non-searchable (last name, for example). Another strategy: you might only return a hit on (for example) “Smith” if the result appears between anchor tags; in this way, non-linked profile fields would automatically be excluded. The first kind of solution is probably the better one, and I imagine it will be quite easy once field-specific profile search comes along in BP 1.3 https://buddypress.org/about/roadmap/