BuddyPress.org

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.

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

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.

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’.