@xrun Does the Load More link work without that filter in bp-custom.php? Sounds like it might be a javascript issue unrelated to the custom function.
No, that’s just for switching which site buddypress runs on in a multisite install. If you want it to work on every site, use this:
define ( ‘BP_ENABLE_MULTIBLOG’, true );
@DJPaul
I did not see that but added now. If more multisite subfolder use bp-default theme do I have to add each ID like this:
define ( ‘BP_ROOT_BLOG’, 2 );
define ( ‘BP_ROOT_BLOG’, 3 );
define ( ‘BP_ROOT_BLOG’, 4 );
If I remember correctly, if you call html_entity_decode() with some character format text on PHP4 (latin1?), there is a log warning, “cannot yet handle MBCS in html_entity_decode().”
You’re probably best putting this as a bug on https://trac.buddypress.org/ so that someone can investigate
Found it here
bp_core_new_subnav_item( array( ‘name’ => __( ‘Home’, ‘buddypress’ ), ‘slug’ => ‘Home’, ‘parent_url’ => $group_link, ‘parent_slug’ => $bp->groups->slug, ‘screen_function’ => ‘groups_screen_group_home’, ‘position’ => 10, ‘item_css_id’ => ‘home’ ) );
@r-a-y do you know where to change the groups home tab link? It’s pointing to /home and I just want it to link to the groups main page.
I agree we need to get trunk synced with branch, and work toward keeping it the bleeding-edge version once again.
I’ve edited your topic title to be more specific to your post.
Your original title – “doubts about buddypress” – is not even related to what you have written.
re: filtering the activity stream – unless I’m mistaken, it’s not possible to tack on multiple scopes or user ids to the activity stream loop.
re: single-level threaded stream – I’ve thought about this myself. I’ll look into this when I have some time.
Has anyone used the tags to sort groups into, well , groups? I have over 100 groups the site I am about to launch and a tabbed UI would be awesome. Can build it myself, but wanted to check and see if anyone had done it already.
Trunk not being merged with 1.2 branch is holding back a few patches from me
Welcome Pack will also do this in next version; I’m working with @crashutah on it. (end plug, hehe).
@r-a-y
“If it doesn’t require moderation, it shows up in the activity stream.”
Still a problem when below option unchecked.
Discussion settings:
Before a comment appears
An administrator must always approve the comment (unchecked)
Comment author must have a previously approved comment (unchecked)
Use the BP Disable Activation plugin by @crashutah –
https://buddypress.org/community/groups/bp-disable-activation/
Make sure you add a captcha plugin or some type of spam prevention!
@dlittle800 Try disabling all plugins and use default settings.
What version of wordpress and buddypress are you using?
@nuprn1 Might have been for fun but good patch nonetheless, essential bit of security supplying original password and seen in so many apps
@nuprn1 @boonebgorges Btw, thanks for releasing your client plugins back to the community. The 2 of you combined probably account for 30% of the most recently updated plugins. Thanks.
I’d probably dedicate more time to trac patches if I knew or had a better understanding what/where/how and being on the same page/vision for the project. Probably why I stick to plugins, I have a better control over what I think works vs what the collective maybe thinking. (plus i don’t look like a doof since i’m a Java junky vs php guy 
) And what @boonebgorges mentioned – 99% of the plugins I created came from a specific client request – I just like to recycle back to the community.
( just to get on the fun, i sent in a patch today https://trac.buddypress.org/ticket/2517 )
@boonebgorges Your point about plugin development is exactly why I felt a little reticent in expressing my feelings. Plugin development is part of the intrinsic nature of WP and it’s sibling/child modules (I still have a problem refering to BP as a plugin , it’s nearly a standalone app?) and to ask any developers to shift focus from that to the core app is a difficult one. Obviously billing for core development is next to impossible and we all know that – if we’re honest developers – we don’t bill clients for the testing of work or for cross browser conformance or for implementing 17 different image galleries because we want to find a new cool one for clients site etc.
All that none withstanding I do have this impression that there is a lot of plugin development and that this development slightly fractures the strong focus that BP might need?
I also still feel that many plugins – your ‘Invite Anyone’ is a prime example – should really be core modules or extensions much as we have BP ‘Components Setup’ as these plugins enhance and improve part of the core that already exists or add components that one might expect to be core in a social network app.
I would like to see, perhaps?, something along the lines of a Trac milestone when a pretty stable BP is reached (1.4?) that sets out a process for identifying and bringing in certain plugins to the core , but this is probably something better discussed in a dev chat and is looking quite far forward; I also see an issue where the author has put substantial time and effort into development of the plugin and would hope there was some means of recompense given that the plugin would effectively cease to exist as downloadable and donateable
@hnla You raise an interesting point about plugin development vs core development. Speaking from the point of view of someone who makes a living off of WP and BP-related development, I can note that it’s often quite easy to justify the development of plugin-type functionality for a client. The client’s job needs a specific type of functionality not available in, or appropriate for, the core of BP, so it makes sense for them to pay to have it developed as an add-on. From there it generally takes just a bit of extrapolation and cleanup to turn that add-on into something that can be released as a plugin in the WP repo. (If you’re really lucky, like I am, you have paying clients who actually *encourage* these cleanup and extrapolating steps in plugin development.)
It’s a bit harder to bill for core-type development, since so much of core development involves extensive bug testing on a wide variety of different server and software configurations – something that isn’t really required for a specific client project.
Still, this all makes me think about Andy’s awesome post from last year, “Give a Little”: http://apeatling.wordpress.com/2009/09/25/give-a-little/. Now that I’m starting to catch up from my month-long break from BP (honeymoon ftw), I personally am going to start devoting more time to the core project, which I understand broadly as this buddypress.org community as well as the ongoing core development on trac.buddypress.org.
@erich73 very true, it’s been requested before and again now for all and any willing and capable members to start to run through that body of Trac tickets for 1.3, the more experienced might be able to provide fixes or even just set things off on the right track anything like that helps the core team, after that testing is one of the huge burdens that falls on any developer, the more we help in testing fixes the more time the core devs will have. I think that time is the biggest enemy for many of us which is why the more that can muck in the better. Ultimately the speed at which versions are released and the quality of those releases will be down to the wider community, if no one helps out then things will come together but a heck of a lot slower.
This next point is purely a personal feeling but I think it wouldn’t hurt to see a general slow down on plugin writing or feature extending in favour of a little more focus on the core app, but I realise it’s not really practical to expect plugin development to take a back seat and that there are plugins in development that people are crying out for 
Thanks @mercime. My plugin is in active development. It is still early on, but I am really wanting some good feedback on ways to improve it, so let me know your thoughts when you try it out.
