Andy, we’ve had a discussion on IRC long time ago about this ticket https://trac.buddypress.org/ticket/257
And it’s stuck with this WordPress bug https://core.trac.wordpress.org/ticket/8662
Could you push the core devs up there to take a look and commit the patch? It’s a tiny bug, and it doesn’t affect standard WP installations, but it does to BP, and it’s bugging us who live ahead GMT and use our local time as the blog’s time.
Try FeedWordPress and get the posts using RSS Feeds. You do not need contributor rights etc.
The questions still remains unanswered. Do we have to manually edit files when moving wordpress mu & buddypress to a different domain?
Yes, same here. I upgraded both my BuddyPress and WordPress to the latest versions but error still persists.
My BBPress installation cannot find my salt cookies even when I plug them into the install from wp-config.
They do not appear in my WPMU admin options menu.
I always get this message at the end of install:
>>> WordPress “auth” cookie salt not set.
>>>>>> Could not fetch “auth” cookie salt from the WordPress options table.
>>>>>> You will need to manually define the “auth” cookie salt in your database.
>>> WordPress “logged in” cookie salt not set.
>>>>>> Could not fetch “logged in” cookie salt from the WordPress options table.
>>>>>> You will need to manually define the “logged in” cookie salt in your database.
Forum could not be created!
Nevertheless, I get an email saying that the install was successful. But when I go to the BBPress admin in the WPMU dashboard it doesn’t see the installation.
and some of this:
[Sat Feb 7 17:41:14 2009] [error] [client 86.162.51.73] user gigbuddy not found: /
[Mon Feb 9 12:26:44 2009] [error] [client 86.158.64.7] FastCGI: server “/var/www/fcgi/php-cgi” stderr: WordPress database error Unknown column ‘g.status’ in ‘where clause’ for query SELECT id as group_id, slug FROM wp_bp_groups WHERE g.status = ‘public’ made by require_once, do_action, call_user_func_array, groups_admin_settings, bp_has_groups, BP_Groups_Template->bp_groups_template, groups_get_all, BP_Groups_Group->get_all
[Mon Feb 9 12:28:56 2009] [error] [client 86.158.64.7] user damageinc not found: /phpmyadmin
[Mon Feb 9 12:29:53 2009] [error] [client 86.158.64.7] user gigbuddy not found: /wp-admin/
[Thu Feb 12 10:41:55 2009] [error] [client 86.162.51.73] FastCGI: server “/var/www/fcgi/php-cgi” stderr: WordPress database error Unknown column ‘g.status’ in ‘where clause’ for query SELECT id as group_id, slug FROM wp_bp_groups WHERE g.status = ‘public’ made by require_once, do_action, call_user_func_array, groups_admin_settings, bp_has_groups, BP_Groups_Template->bp_groups_template, groups_get_all, BP_Groups_Group->get_all
[Thu Feb 12 10:44:35 2009] [error] [client 86.162.51.73] user damageinc not found: /phpmyadmin
This is what is called “deep integration” over on the bbPress side of things. It is often times shied upon but I feel is very much a requirement for making things look all nice and pretty.
I know for sure it is possible on the WordPress.org side of things as I’ve done it several times, but I am going through my first MU/BuddyPress attempt tonight and tomorrow.
I’ll do my best to see if there are any differences, and report back with what I find.
Actually, it would be the other way around. dbDelta is actually a wordpress function that plugins can call to get upgraded. Andrew mentioned that this would all be sorted out with a plan to address buddypress by the multi-db 2.8 release. The reason you have to comment out all the dbDelta lines of code is due to a compatibility error that will fill your errors logs 
As well, the search breaks with multi-db since it needs to call more than 1 database since one is global and one is for specific users information, it fails. It tries to find a member specific query in the global DB (since that is the one that is called first) and can’t find the info which causes an error.
The multi-db code also puts all user activity tables in the same DB right now (since it can’t spread them around without code to do so), so the only benefit you get is if you need this solution for multiple blogs. It actually created them all in the global DB when I used the move-blogs tool, but wanted to find them in the same DB as main blog. I had to copy all the user activity tables to that DB for it to work. If you start with a fresh install, it will create them in the right DB straight away.
Summing up, by WPMU and multi-db 2.8 and a 1.0 BP final release, it will draw more attention so that the solutions will have a clear goal to shoot for. This is a topic better suited in the Premium wpmudev forums as well I think. Glad to discuss it further there!
Trent
oh thanks Andy this sounds good!
and now i take the opportunity to ask if there is a repository i18n for buddypress in the svn, and, if is yes, how update the language files.
thank you for the great work you do.
Arturo
BPIT Staff
I’d assume for now that you will have to manually add the language file, however in the future it would be nice to support that too.
one thread has one to many messages
one message has one to many recipients
one user has zero to many threads
the squiggly stuff you posted is a serialized array of message and sender ID’s. In PHP if you take that value and use the function unserialize() (or maybe_unserialize() if you are in the WordPress environment) you will get an array full of ID’s you can then iterate and use.
Thanks Burt. That answered my question.
I realize now I didn’t really phrase my question clearly. I have been using bbPress integrated with WordPress.org for a few months now and am very comfortable with how it works, however it obviously integrates much differently with BuddyPress, with group forums and all.
So to confirm, there are group forums and then global forums, and anyone can post anywhere regardless of group membership?
FYI https://trac.mu.wordpress.org/ticket/894#comment:3 has added a hook so we can customise the subject line of the email sent to new users (accounts) after activation.
MartinNr5.
Clear your cookies, then after logging in both places, view your cookies in like Firefox. I am assuming that they should be named something like wordpress_ and wordpress_f5433ed3c296d4543 (where the letters after the underscore is a hash).
In both your wordpress and bbpress config files, add the following:
define('COOKIE_DOMAIN', '.example.org');
define('COOKIEPATH', '/');
define('COOKIEHASH', 'f5433ed3c296d4543');
Log out, clear cookies, and it should work.
Don’t know about the groups, but as far as your subdomain problem… you can only set these options (between user.domain.com vs. domain.com/user) when you install WordPress MU. Once you set that during install, there’s no way to change it after that. If you have to change it, you have to reinstall WordPress from scratch and pick the right installation options.
I will go out on a limb to say that what looks like a bug at first is often times just normal user error.
I consider myself a seasoned PHP/SQL/Linux/WordPress/bbPress veteran, and to be honest it took me installing and reinstalling MU/BuddyPress 4 times before I was able to follow the instructions correctly. Each time I would have sworn on my undead mothers grave that I did everything right, but alas…
So a tip to you all, if it isn’t working, it just might be because of something you don’t know you didn’t do… 
Now I’m trying to use Burt’s plugin in combo with the Block Admin plugin to prevent users from accessing the dashboard but no luck. I have new blog owners defaulted to author, and yet they still get access to the dashboard.
For what it’s worth, I’m using it and I can get to the dashboard once logged in via ‘URL/wp-admin’.
Of all the solutions, Burt’s plugin seems to work best, and of course if we can redirect the login page to whatever page we want to, it would be even better.
However, the only problem I have encountered with Burt’s plugin is that after I upload it, I can not access the dashboard as the administrator either! To get in the admin area, I have to remove the plugin again. Perhaps, there is a shortcut of something to avoid this.
Sorry Burt. The questions don’t seem to end. But I guess that’s how human beings have continued to evolve, eh?
Thank you
Vida
Were you using the same version of WordPress MU when you were testing with Beta 1?
was not trying to be rude, sorry if it came off that way. This script was used with the Beta 1 of BP without issue, so whatever changed in the Beta 2 that is related is what I need to find a workaround for. Just asking for some guidance/assistance. The script is textbook php so it works fine from that respect…. I have 2 databases in mySQL, 1 that is for the WordPressMU and Buddypress, and another that I created separately for another part of my site….the second database is the one the script is calling.
Any thoughts?
burtadsit
function oci_login_redirect($redirect_to, $set_for, $user){
$redirect_to = bp_core_get_userurl($user->ID);
return $redirect_to;
}
add_filter(‘login_redirect’, ‘oci_login_redirect’, 10, 3);
How do I redirect to the user’s new blog versus their profile?
Thx
Okay so i followed the instructions here https://mu.wordpress.org/forums/topic.php?id=3173&replies=3#post-19388 .. here’s what I did..
# chown nobody -R blogs.dir
# chgrp nobody -R blogs.dir
# find blogs.dir -type f -print -exec chmod 644 {} ;
# find blogs.dir -type d -print -exec chmod 755 {} ;
but it still doesn’t seem to work… any idea what to do?
blogs.dir and some other folders will probably need to be chown’d to the user and group that runs the webserver. Apache2 by default (I think) uses the nobody user account, so I’m assuming that’s what your host uses.
Whilst 777 will let everything access it, from a security perspective, you should really go for 755 permissions and check that the owner/group of the files is the same as that of the webserver.
BTW if you’d have tested uploading an avatar on a plain WordPress MU install, you’d have had exactly the same problem. This isn’t buddypress.
