Eventpress works great to me in WP 3.2.1 multisite and BP 1.2.9. I have used the plugin Multisite User Management to mange all the users roles and to change them to the Event creator role in the main site.
By the way, the only bug that I have found is that the link created in the admin bar in: My account -> Events and My acoount -> Events -> My events don’t work propertly, if I click them, they go to the site_url
Anyway, great plugin, congrats! 
You can also create your own BuddyPress component that way things you post into it will work similar to Facebook’s activity stream.
Thanks for the tip @juanmaguerrero , certainly very clever.
@Webbasica I accomplished that by using the MultiSite feature… each “fanpage” is a blog. When I started my community I studied Facebook Fan pages and concluded that they should not be able to send private messages to their fans, nor tag members on pictures nor make mentions ( @username). Therefore I opted for using “blogs” as fanpages, any business or brand or institution can create a blog and post things, entries, pictures, etc. They can have a king of profile, an about pre-set page and their activity wall is a page with almost no content and all comments! This works also grate if you’re using oEmbed plugin which allows you to paste youtube videos urls and it will be the same than embedding them… so I just think they’re perfect. Let me know if I can help you further… regards
That sounds like a bug. Could you open a ticket on trac.buddypress.org please?
Well I managed to import 30k members and 297k forum posts into the new bbpress plugin. Now we just need the plugin to work with buddypress and I’m set.
This should provide a good test prior to our updating the larger sites with 500k+ members and millions of posts…
@larrysmith1000, @Arwym, @FitzUCF, @janismo, @hnla
I don’t know if anyone is still looking at this, but I think it is a topic that is worth pursuing. What seems to be getting lost though is what it takes to do the job.
A facility like Justin Tadlock’s members plugin is a big help. It provides a mechanism to define and edit roles and apply them to users. That covers a lot of territory. However, unless the content management part of the software looks for and enforces those roles, it is meaningless. Justin provides a facility to do that if what you are talking about posts/pages and potentially custom post types. That is fine for WP content or even things like BuddyPress Docs where Boone implemented it as a custom content type (although I haven’t look at the details of his implementation relative to permissions). However, BP adds additional content types. And it is not just FORUMS. Groups are a content type. Private messaging is a content type. etc.
That is where the current_user_can() checks make sense. Users should have permission to perform actions. That doesn’t necessarily mean new roles, but it does mean distinct capabilities. Those capabilities can then be assigned to any role that makes sense. But the capability list needs to be published like it is for WP https://codex.wordpress.org/Roles_and_Capabilities
The mechanism for assigning capabilities to roles and roles to users and doing the actual check is all WP. It’s already there. Justin provides UI to access it. What I am seeing missing in BP is published string literals that have meaning in terms of capability sets and I assume the current_user_can() checks that actually make it happen. (I looked for it on Google and this is where I was directed!)
@DJPaul you talked here in terms of BP1.3, which is now 1.5 I believe. Did any of this actually make it into the code? If not, it sure would make sense to me to find it’s way on to a revised RoadMap.
My 2 cents!
As for BuddyPress, delete spammers and spams with links leading to viagra, etc. Re SEO plugins and sitemaps, these are supposed to help with Google ranking not the other way around. Site URL?
https://codex.buddypress.org/home/
Currently setting up and updating docs for BP 1.5 – feel free to list down specific information you need here and/or even submit articles as well.
I was posting on a StudioPress forum about their efforts to upgrade their Genesis Connect plugin for compatibility with v1.5 and asked about the recommended install process (uninstall/re-install). The answer in part was:
“There are BP 1.2.9 functions calls in GC 1.0.7 that are not in the BP 1.5 beta-2. If you leave GC 1.0.7 active and upgrade BP, you end up with call to undefined function errors both in the front end and in the admin area of your site.”
BP 1.5 seems like a major move and, from what I’ve seen as I begin to look at it, a very beneficial move. However, it also seems, from the discussion in this forum, to be a move with big impact in terms of plugins. I’m new here, but on that basis I have a question:
Would it have been possible or make sense to ease the transition in some cases by providing some adapter functions that would translate old replaced functions with re-directions to their new counterparts? The old functions could then be identified as deprecated and removed at a later date, but in the immediate horizon some plugin modules might continue to work rather than needing to be modified or abandoned? Simply dropping stuff without fair warning seems drastic.
It might not be possible in all cases, but it might help with the transition. I know a lot of people want to move forward to the new v1.5 and this type of code strategy might help.
Just a thought.
BTW – I’m beginning to play with beta 5029 and it looks fantastic! Great job … you guys did a lot of good work!
Thanks a lot. In our case each site on the network will be using buddypress, but they won’t be sharing posts / comments between them. Also, all of these sites are sharing a single child theme. I suppose I could add a condition to the function to whitelist only the current site id, preventing updates streaming in from any of the other sites. Will give it a shot.
Thanks 4ella. I think this is a common sense extension of BuddyPress, so I’m looking at sponsoring a plugin for the community. If I do, any advice on how let the community know in addition to putting it on WordPress?
It *should* change it. That setting’s implementation in 1.2.9 had a few issues, so I spent a bunch of time in 1.5 making it better, but that doesn’t help you. When it’s set, you are trying to pick a user from the member directory rather than copy/paste the same URL, right?
Hey Paul,
Yeah that was my very first port of call a couple of days ago. It didn’t seem to do the trick 
It’s got me stumped. It’s the last bug left for phase 1 of the project and it’s got me stumped!
Did you try setting the name compatibility constant as per that codex page you linked to in your post?
Thanks @modemlooper. I had been considering having to do an option like that. I’ll give that one a whirl tomorrow and see how I go.
Hey @djpaul, yeah they all have spaces in them. All the existing users come in with spaces in their name in a First Name, Last Name kind of way. I tried changing the ‘Nickname’ and ‘Display Name publicly as’ fields in my own profile to see what would happen yesterday and that obviously doesn’t have anything to do with it as you can see here: http://edgeqld.org.au/members/Bronson%20Quick/
I know the site was originally WordPress MU then it went to WP 3.0 then up to WP 3.2 and installed the BP theme and plugins on top of that. I didn’t have any existing users on my staging site so didn’t hit this problem til we went live….now I’m cowboy coding fixing bugs and I’m completely stuck with this one!
do the “broken” user names all have spaces in them? (in general)
Okay, all of my pages like this are also not being found. All of my logged-in admin dashboard stuff works ideally…then when I go to the actual site, the links all go to a “ERROR 404 – PAGE NOT FOUND”
I am hosted on hostgator, and I am not sure I created the blog.dir correctly when I went multi-site.
Thanks anyone who can help!
why not post a notice to have users change their username using this plugin
Allow Your Users to Change their Username on your BuddyPress Based site
