They should just use activation mail again, works the best.
There already exists a topic concerning these spam sign-ups. Haven’t had any problem with this yet, but that’s most likely because I have my wpmu/buddypress/bbpress in dutch..
@jjj I checked in the Aug-Sep timeframe and the hooks weren’t there in BP to do a true segregation by site. I have had a lot of requests for it from people using my multi-site plugin. I currently have 3 plugin releases/re-releases I’m working on. All 3 are at the tweaks & testing stages. Once those are done, I’ll be looking at BP & multisite.
https://buddypress.org/about/roadmap/
Use the development versions if you’re waiting and waiting, you’ll get the fixes first then.
It’s really just about reading the instructions. if you read the instructions step by step then it’s not hard at all.
Thanks Ray,
Ill give this a try and get back.
Reporting issues with the WordPress blog export function should go on to the WordPress forums or Trac. It’s not to do with BuddyPress.
Please everyone keep posts here on topic, civil and polite.
Yes, I am using sub-domains. No, I did not go back and forward.
If the plugin does not work with sub-domains … <i>which, let’s face it, are pretty core to WPMU</i> … then I suggest that it would be good practise to add a block, warning or at least instructions during the setting up process which prohibits the use of the plugin.
There is nothing in the readme either.
‘example’ and ‘example.com’ is just the usual ‘example’ computerspeak not the actual name used.
The header error as above happen on the first and every attempt at blog creation, not going back and forward.
I went forward until the white error page. I could neither go back nor forward. When I came out of the plugin set up, I discovered that it had partly set up the blog on the home page (<i>but that other elements of groupblog did not work of it did not work</i>). It stalls on stage 3.
I also found that previously made groups (<i>made before the groupblog installation</i>), did not have a blog and I could not make a blog for them.
As for the rest, see my perfectly polite and helpful comments … here.
Can I also say, for the future, it would be a really great feature if, when removing the plugin, it removed (or gave the option to remove) all the changes it made to one’s database.
Its a really great idea but perhaps … in all fairness … you should reduce it from a 1.0 + release for just now until it does work?
Marius,
If you read the English, it was a comment regarding the WordPress Export function (which exports posts and page but not it seems the blogroll) … not your plugin.
That seems like an awfully strange and unnecessary omission … and a PITA to administer when it comes to having rebuild a community by hand.
I am sorry but spending one’s times to ‘beta testing’ other folks’ software, and bug reporting back, is also service to the community and improves it.
Nothing good comes from being oversensitive about fair observations … especially those addressed in polite enough terms to others.
@anointed, I think the best way to do something like this would be to extend the existing multi-site plugin(s) and introduce a method to either serialize the sites that users belong to and add it to a _usermeta field, or insert/update/delete blog_id/site_id to the _usermeta every time a user is added or removed and check against those meta’s on every page load if the user is logged in.
The problem comes from situations where site-admins technically are users on all sites, and how to deal with collisions where users can be added to blogs without being added to sites, if that makes sense?
What you would need to do is hook into all of the places where users can be added/removed from blogs, and add your own actions to those functions to perform your special tasks, which-ever you choose to do.
Then… Once that’s all done… You’ll need to modify the members directory to sniff out only the users that are in those _usermeta values that you assign them to. In my opinion, this is a modification of the kind of magnitude best left for professionals or tinkerers with lots of extra time to test and make sure you don’t corrupt the relationships between users, sites, and blogs.
There are functions already to see which users are already part of which blog_id’s, but that doesn’t really work for all users across any particular group of blogs based on a site_id. I haven’t needed to do something like this myself so I can’t say for sure, but I haven’t seen a core function to find users belonging to particular sites… It would require first checking the wp_blogs table for all blog_id’s matching your site_id, and then checking the roles and caps for users that match.
Silly questions…
- Are you 100% there’s no deep integration?
- Maybe put some echo’s in the original bbPress files and see how and when they’re getting included?
- Is there a widget or plugin that’s preloading bbPress before BuddyPress?
- Do you have the old integration plugins disabled?
- Can you confirm in wp_sitemeta that “bb-config-location” is pointing to the new bb-config.php and not the old one?
Just a few things to look at and consider…
You are right ! That’s it !
Thanks. I added that instruction to the readme.
wooooo….. ghostly
actually i have no idea why either… but i know that i had to have at least one user with all the fields filled to see the field names in the list…
That’s stupid
Thanks, I had forgotten about his.
But more stranger, I don’t see anymore the fields names in the select boxes of the admin options after having installed the plugin… Weird, uh ? I didn’t change a thing in the code about this…
the auto-install of this plugin is not working, Benoit will have to work this out… files structure is wrong.
you have to install the plugin sitewide… that’s the only reason why the panel is not showing..
and i can say that having a bp-plugins folder would avoid a load of errors like this, making support for these addons a simplier life.
Got problems with the admin menu of that plugin.
The BuddyPress admin panel does’nt expand, and instead, it goes to “wp-admin/bp_profile_real_names” which is the broken url of my plugin (and should be : wp-admin/admin.php?bp_profile_real_names).
The page itself is broken.
// Adds admin menu to WP Dashboard > BuddyPress
function bp_real_names_menu() {
add_submenu_page( ‘bp-general-settings’, __( ‘Real Names Options’, ‘bp_profile_real_names’ ), __( ‘Real Names Setup’, ‘bp_profile_real_names’ ), ‘manage-options’, ‘bp_profile_real_names’, “bp_real_names_options” );
}
add_action(‘admin_menu’, ‘bp_real_names_menu’);
Please help ! I don’t see where the problem is.
Thank you gentlemen.
I would love to get my theme working via official means. I’ve tried for a few weeks now to follow Jeff’s instructions (which he has kindly provided to me for the third time above) with no luck.
Because all my bp CSS and formatting is written for the now deprecated bpskeletonmember theme, following the “I’ve used a WordPress theme for my blog with the default BuddyPress member theme†instructions from the above link results in a member theme without my CSS after I delete the bp-themes directory. That’s why I was asking how to salvage the deprecated theme. I’m a little desperate now as I only have until weeks end to work on this.
Hi!
I’m looking for the same thing and I wonder if you were able to figure this out. help, anyone?
/public_html/wp-content/themes/
By stock you mean buddypress-home?
@Nervo thank you so much
Just found out that we got listed on WPMU.org’s 17 of the Best and Beautiful!. We’re all ecstatic here.
http://wpmu.org/buddypress-eye-candy-17-of-the-best-and-beautiful/
The resolution from apeatling (in response to https://trac.buddypress.org/ticket/1356):
If you are allowing @ symbols in usernames, then please add this to your wp-config.php:
define( ‘BP_ENABLE_USERNAME_COMPATIBILITY_MODE’, true );
https://codex.buddypress.org/how-to-guides/changing-internal-configuration-settings/
Worked for me!
