BuddyPress.org

Cool…there have definitely been some funny things with JS caching today. Glad it’s sorted!

Hm – working ok for me. Are you running any caching plugins?

James makes a good point. If you use a plugin (or custom code) that registers a non-standard versions of jQuery, you will have problems with the JS in bp-default (as well as WP and many other plugins).

Well, it will be a bit more complex. But we’ll do our best!

https://wordpress.org/extend/plugins/buddypress/ 🙂

Confirmed. This is a bug in trunk, for multisite. I tracked down the problem and am about to commit a fix. https://buddypress.trac.wordpress.org/ticket/3313 svn up your BP installation to get the fix.

Thanks for letting us know, and for running trunk!!

@ddean BTW, this is sort of off the topic, but it’d be great if you got involved in core development a bit when we start working on 1.4 development. We’ll be shifting groups to a custom post type, which means that we’ll get things like post_parent for free. It’d be great for BP to get your […]

Yeah, filtering the class name rather than $this->current_group would probably save some cycles. But we don’t really have a precedent for doing this elsewhere in BP. It’s worth discussing on a trac ticket when you get around to opening one 🙂

Is it not possible to hook in late to bp_setup_globals (maybe priority 999) and swap out the current group? That would let you replace the value in the $bp global before the page rendered, without subclassing BP_Groups_Component. Another option: Why don’t you filter bp_current_action()? If current component == groups, then return whatever group_id…[Read more]

Try this: https://codex.buddypress.org/developer-docs/group-extension-api/

Hi there, my wife just had a baby a couple days ago, so I can’t look at this right now, but I don’t want to forget about it. Could you open an issue ticket at http://github.com/boonebgorges/buddypress-docs explaining the problem, along with details about your setup? BP WP Docs versions, theme name, other plugins running

To the best of my knowledge, this plugin does not make any changes to your database. Have you deactivated the plugin?

It’s simply not possible that deleting the database and reinstalling would cause this problem to arise again, unless you also had the problematic plugin activated.

It is very complicated to build a general purpose tool for something like group imports. The data that people have in CSV format varies extremely widely from case to case. The amount of extra coding that would be needed to build an all-purpose import tool (in contrast with a single-use, custom-built tool) is enormous. For […]

I don’t see a problem with that number of groups. You can see how BP handles group avatars in groups_screen_group_admin_avatar() (bp-groups.php) and the avatar functions it uses. This process is a bit tricky, and is probably going to be the biggest challenge of the whole thing. My advice is to look at the way the […]

It’s been fixed on trunk and in the 1.2 branch.

I’m looking at the code, and I think you’re right. Could you post a trac ticket please?

Well, it’s not *that* simple. You still have to assemble the $args array, which will take a few more lines of code. And setting a bunch of groupmeta, depending on the complexity of your CSV, may take a while as well. But yes, in essence, this is the idea.

Generally, for this purpose, there will be no need for direct SQL manipulation. The general idea: `$data = fgetcsv( $csv ); foreach( $data as $d ) { $args = array() // do some stuff with the $d array to set up args $group_id = groups_create_group( $args ); groups_update_groupmeta( $group_id, ‘whatever’, $d ); // again, whatever […]