Forum Replies Created
Oops, you’re right. Upon closer inspection it did not work without changes for me.
Instead of changing the bbPress side, I decided to make TinyMCE a bit more bbPress compliant. I wrote a little plugin which posts double line breaks instead of paragraphs. You can find it here:
Just in case anyone else (like me) stumbles over this thread on the search for an WYSIWYG editor. The problems discussed above seem to have disappeared. I just added TinyMCE 3.2.5 to my bbPress 1.0.1 installation and it works like a charm without modifications besides the removal of obviously unsupported elements.
But how do I change the corresponding links? If I just translate “topic” in the htaccess, bbpress will understand the translated urls but still generate links with the original “topic”, wouldn’t it?
Found the difference: The user for whom only the login name is shown indeed does not have a bbpress display name, but a buddy press display name. I’m not exactly sure why one display name got transported over to bbpress and the other did not, but I guess that is not a topic for this forum.
I’m still searching for a way to get the login name for users with a set display name, though…
Weird… I have one user where only the login name is used, but another one where the display name is shown. I’ll come back to that if I find out what the difference between those two is.
But in the meantime, another problem arose: How do I access the login name when the display name is shown? I need the login name to build the link to the user’s buddypress profile page. Is there a template tag which (always) returns the login name?
Thanks. I manually added your fix to my installation and it seems to work fine.
For the time being I could fix the problem. Since I do not know what the implications are, it would probably still be better if one of you guys would take a look on it.
Line 654 and 655 are:
if ( true === $elapseDelay )
add_option( ‘disable_fsockopen’, $endDelay, null, true );
Since the forum works fine most of the time, I assume that add_option thing isn’t terribly important, so I just extended the if statement:
if ( true === $elapseDelay && function_exists(“add_option”))
Couldn’t see any negative side effects yet, but since this error only appeared sometimes this might be an illusion. In any way I have no idea what this is supposed to do in the first place, so it’s a bit of blind hacking…
I think I almost solved it now. For some reason I had $bb->authcookie and $bb->logged_in_cookie set to ‘wordpress_logged_in_’. Probably due to some debugging oddysee. I removed the autcookie-setting and now cookie sharing and admin access are working. Yay!
The only downside is that I can not access the admin area when I used WPMU to log in. But when I login over bbPress it works, so I guess that is an acceptable loss, since it affects only the admin and not all users…
Nope, didn’t help.
I narrowed the problem down a bit further, though. As soon as I add the following line to my bb-config, cookie integration works but bbpress-admin-access breaks:
$bb->logged_in_cookie = ‘wordpress_logged_in_’;
Thanks, but unfortunately that did not help. I still can’t access the bbPress admin area. Any more suggestions?
Thanks to sambauers I got the login working across both systems now. The important trick is to add the following line to bb-config.php, unless you are using WordPress 2.8:
Now I have only one problem left: I cannot access the bbpress admin area anymore. I instantly get redirected to the forum. Any ideas what might cause this?In reply to: upgrading to RC1 breaks WP cookie sharing (for me).
Yep, that solved the problem for me as well. Thanks a lot! Please post a note somewhere where everyone will see it because I bet this will cause a headache for numerous people…
I am having the same problem as well. Using WordPress MU 2.7.1, bbPress 1.0-rc-1 and buddypress 1.0. WPMU and bbPress successfully share the user database, but users still have to log in seperately.
WPMU seems to store the login information in a cookie called “wordpress_logged_in_”, while bbpress uses “wordpress_logged_in_[bunch of letters and numbers]”.
I already tried adding “define(‘COOKIEHASH’, ‘[same bunch of letters and numbers]’ );” to wp-config.php, but it had no effect whatsoever. No hash appeared in the wp-login-cookie.
I also tried making bbPress use “wordpress_logged_in_” (without the bunch of numbers) as login cookie. This resulted in the same cookie name being used, but the logins were still not shared. When I switched between bbpress/wpmu, I got logged out from the application which was the last to be logged in to.
Interestingly, there is another hashlike string behind the user name in the value of the cookie. Like this: “admin%[bunch of letters and numbers]” This hashlike sting is different between wpmu and bbpress. Even for the same user.
I would guess that means that some hashgenerating constant is off, but I do not know which one. I synched those with their bbpress equivalents: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, LOGGED_IN_SALT, SECURE_AUTH_SALT.
For AUTH_SALT, LOGGED_IN_SALT and SECURE_AUTH_SALT I did use the values from the wp-config.php because I could not find them in the WPMU admin interface. I guess that’s a difference between WP and WPMU?
What am I missing?
I think I had the same problem. Did you get the message “Forum could not be created” when you chose a new username?
I just installed without integration and integrated afterwards. This killed my admin access, but I could restore it with the plugin which was mentioned in some of the sticky threads.
Both installs now successfully share the user database, but I am still fighting with cookie integration… *sigh*