[_ck_]

Note that bbPress is not a finished final product. It’s pre-release and therefore in a state of flux. bbPress has always been a bit behind WordPress changes. If you are using bbPress, you are considered an “early adopter” and therefore you have to accept that things aren’t going to be perfect.

No one but maybe Sam or MDA can say when bbPress will have a release that’s 2.6 compatible. There is code in the trunk that supposedly will work but I wouldn’t recommend using the trunk. It has to be ported to the 0.9 branch and then tested. I suspect they may even wait for the 1.0 beta release and I don’t know if that’s two weeks away or two months away.

Again, there is nothing special about the WP 2.6 release – it only has a handful of extra features and no security bug fixes over 2.5.1 – in fact people are having a bunch of little problem with 2.6 still so why rush to upgrade? I was able to easily downgrade back to 2.5.1 with no problems.

[_ck_]

It’s kinda (good) crazy but there’s actually a role key for “recount”.

update: you can make a plugin to give recount access – it will only work for those that can access admin panel

make this into a plugin:

<?php

/*

Plugin Name: Add Extra Caps

*/

function add_extra_caps($caps) {

$caps['recount'] =__('Access the recount administration panel');

return $caps;

}

add_filter( 'get_assignable_caps', 'add_extra_caps');

?>

Install and activate it, edit their profile and check the ability for them. Then they should be able to access it.

You don’t even need to keep the plugin running after that, it can be deactivated/deleted until you want to take away the ability.

[_ck_]

Security considerations and table of contents added.

A bit more later.

Ragekage, to make a plugin, just copy all of the code for the function from pluggable.php inbetween the IF statemate and then edit as desired. Add the simple plugin comment header and save to your desired filename.

[_ck_]

As long as WordPress was installed first and you were using wordpress tables for users, you should be fine.

I’m not sure why you don’t just roll back to 2.5.1 though.

[_ck_]

Malfhok, you’ll discover WordPress 2.6 is maintaining a separate set of cookies to bbPress if you trying logging out and back in. Also try logging in as a regular user and notice you don’t have login sync anymore between the two programs.

[_ck_]

== Security Considerations when Integrated ==

If for some reason you are on a shared server that uses subdomains and you do not own/control the entire domain (ie. myblog.example.com johnsblog.example.com) or your URL has a tilde in it (“~”) ie. example.com/~myblog/ and you do not own the entire domain (ie. earthlink.com) my cookie advice above is not a good idea and you will have to customize – ask for help.

The reason why is related to some of the cookie changes in WordPress 2.6 – essentially cookies set to the

domain of “.example.com” will get transmitted to the server for ANY subdomain on the server (myblog.example.com will also see the cookies for johnsblog.example.com) The same thing goes for the cookie path in that cookies set to the path of webroot (“/”) will be sent to both example.com/~myblog/ as well as example.com/~johnsblog/ – malicious code on another subdomain or path could snoop on the cookies and steal your admin access to your blog/forum or pretend to be another user.

WordPress 2.6 (and a future version of bbPress) use separate cookies for admin access that can be locked down to very specific paths as well as different cookies for SSL access. This is an attempt to make sure that cookies which give admin access get transmitted as little as possible and only to the specific server/account that needs it so snooping hackers can’t spoof you.

Note this is only a concern if you do NOT control your own server (ie. other people can run PHP on YOUR domain name) or perhaps if you run a WPMU setup. Otherwise, setting the dotted cookie domain and webroot path is the simplest way to get integration cookie sync.

[_ck_]

== Users Registered via bbPress appear as “anonymous” in WordPress ==

This is a bug on the bbPress side where it does not define and insert a “display name” during registration. See this post for a fix (which should be done via plugin and not a core edit). I suspect it will be fixed soon in a newer release.

[_ck_]

== Loss of Admin Access ==

It is possible (most likely during REVERSE integration) for admin access to be lost on the bbPress or WordPress side after you integrate a new install. This is because the role of keymaster is stored in the user-meta and if you have gone from BB_USERS to WP_USERS (and BB_USERMETA to WP_USERMETA) , suddenly there is no longer a level set for the user. So the password/login will work but not admin access.

Fixing this requires the role to be inserted back in the usermeta. This used to require editing the table (ie. with PHPMYADMIN) but I also created a basic plugin to handle the most basic case. Note it requires the keymaster to be user #1. If not, you will have to “hand edit”.

[_ck_]

== Integrating WordPress and bbPress Roles ==

Unfortunately I have no experience in this area as it’s a new feature but maybe someone else can contribute. Seems fairly straightforward though and can be found at the bottom of the integration admin menu page.

[_ck_]

== WordPress & bbPress Cookies ==

We’re going to ignore the new WordPress 2.6 cookie method for now and focus on 2.5+0.9 (2.6 triples the complexity)

FIVE things must be identical in WordPress and bbPress configuration for cookies to be sync’ed and logins to be shared:

1. DATABASE secret key

2. wp-config.php/bb-config secret key

3. cookie DOMAIN

4. cookie PATH

5. cookie hash

If ANY of these are not the same, you will get a weird effect where you can be logged into WordPress and not into bbPress or visa-versa and you won’t be automatically logged into one or the other.

#1 can only be seen under /wordpress/wp-admin/options.php and copied to /bbpress/bb-admin/options-wordpress.php

#2 must be edited in each file as appropriate

wp-config.php

@define(‘SECRET_KEY’,’blahblahblah’);

bb-config.php

@define(‘BB_SECRET_KEY’,’blahblahblah’);

#3 & #4 should be edited in each file as appropriate

#5 is the tricky part – in theory bbPress should create the same hash as WordPress if #1 & #2 are the same but sometimes it gets it wrong for one reason or another. You can override the hash and force it to be identical in both programs. There is no easy way to see what hash WordPress is using, you either have to examine your cookies with a bookmarklet or web developer tool or install a plugin that lets you see/edit your WordPress cookies.

[_ck_]

== The Shared User List (table) ==

The most essential concept to all integration is that WordPress and bbPress just share the same list of users in the database.

This is where some people make a mistake right at the start and accidentally create or keep using two separate copies of the user lists (usually one complete with many users and the other just themselves because it’s a fresh install of bbPress).

If you find that after your integrated install of bbPress that it cannot “see” any of your WordPress uses, you must check that bbPress is using both the correct DATABASE, and the correct TABLE.

The most common name for the user table is called WP_USERS

The WP_ is what we call the prefix and indicates that it’s part of WordPress by default. If bbPress is running by itself and not integrated, the prefix is likely BB_. Unless you are doing reverse integration and don’t want to change the table name, there is a 99.9% chance that your user table should be WP_USERS.

If your bbPress cannot see the WordPress users, check your “User database table prefix” in the bbPress integration admin menu OR add this to the bottom of bb-config.php

$bb->wp_table_prefix = 'wp_';

[_ck_]

== Installation locations for WordPress vs bbPress ==

There are actually a few different arrangements to where WordPress vs bbPress can be installed and I suspect this is where some problems and misunderstandings crop up.

1. WordPress in the “webroot” (highest level directory) and bbPress in a subdirectory.

<– WordPress

|

|–forums <– bbPress

(or visa-versa)

2. bbPress in a WordPress sub-directory

|-blogforums <– bbPress “under” WordPress

(You can make this work but it’s a bit messy, no?)

3. WordPress and bbPress each in their own directory

|–blog <– WordPress

|

|–forums <– bbPress

(I like this methed best, seems the most “logical”)

4. WordPress and bbPress both in the “webroot”

(or other same directory)

This is not recommended at this time. Technically it can be done but you are completely on your own to make it work properly and it’s not designed to work this way. BackPress may eventually change this and even make it the preferred way to function.

Otherwise, 1,2 & 3 are perfectly valid ways to operate. IMHO #3 is easier to manage but that’s that’s just personal opinion.

Why do install locations matter? Most importantly it’s because of how the shared cookie paths are handled. If you don’t change the cookiepath to the webroot (“/”) like I suggest below, one program may not be able to see the other program’s cookies.

[_ck_]

== Regular, Reverse & Complex Integration ==

1. If you already have WordPress and are installing bbPress, that is what I called “regular” or “simple” integration and is the most straightforward.

2. If you first have bbPress installed and are trying to install WordPress afterwards, that is what I call “reverse” integration and while it’s definitely possible, it does require a bit more work initially.

== Levels (or Depth) of Integration ==

There are two levels of integration:

1. User information is shared across both WordPress and bbPress – logins are persistent across both programs and they are essentially “aware” of each other but they still run “standalone” – one at a time, instead of both together – I call this “stand-alone” or “simple” integration.

2. bbPress can be made to run “within” WordPress (or visa versa) – where both programs are fully executed for every page loaded – I call this “full”, “deep” or “complex” integration – and I actually advise AGAINST it heavily. There are various reasons to try to avoid this, including server loads and technical issues with the way templates and plugins are processed.

However it definitely can be done and many people have made it work but future products from Automattic like BackPress will make this process much better and I advise to avoid it for now if possible.

If you insist on trying complex integration you can find some helpful instructions from Aditya Naik over here. They are for bbPress 0.8 so they are a little out of date. Instead of “config.php” use “bb-config.php” and you should NOT install the three plugins he recommends as they are no longer needed in versions 0.9 and 1.0

[_ck_]

== Instant Integration for Power Users ==

If you’ve just installed bbPress 0.9 into a WordPress 2.5 website and followed the integration setup questions but it’s just not integrating correctly and you feel you are fairly web savvy you can try this “shortcut”. (Or read the other posts below for more “theory”.)

** If you have lost admin access entirely, do steps #4+ first and then come back to 1,2,3

1. open this url in a browser window to edit:

http://your-website-url.com/bbpress/bb-admin/options-wordpress.php

(/bbpress/ is your install directory for bbpress)

2. open this url in another browser window for reference:

http://your-website-url.com/wordpress/wp-admin/options.php

(/wordpress/ is your install directory for wordpress)

3. you MUST copy the secret text

from /wordpress/wp-admin/options.php

to WordPress database secret

on /bbpress/bb-admin/options-wordpress.php

They *MUST* be IDENTICAL

4. open to Edit bb-config.php in the bbPress directory

5. open to Edit wp-config.php in the WordPress directory

6. bbPress 0.9

the define("SECRET_KEY","blahblahblah") in

your WordPress wp-config.php MUST MATCH the

define("BB_SECRET_KEY","blahblahblah") in

your bbPress bb-config.php

bbPress 1.0

instead of SECRET_KEY in 1.0 there are 3 replacements

AUTH_KEY

SECURE_AUTH_KEY

LOGGED_IN_KEY

you can go here to generate a complex secret_key(s):

bbPress 0.9: https://api.wordpress.org/secret-key/1.0/

bbPress 1.0: https://api.wordpress.org/secret-key/1.1/

(note you must add the BB_ part for the bb-config.php)

7. Copy all these items into the bottom of bb-config.php and edit as required:

$bb->wp_siteurl = 'http://your-site-url.com/blog/';

// that’s your WordPress URL, not bbPress

$bb->wp_home = 'http://your-site-url.com/blog/';

// almost always the same as siteurl unless you tinker

$bb->wp_table_prefix = 'wp_';

// should almost always be wp_ unless you tinkered

$bb->user_bbdb_name = 'username_wordpress';

// this is the MYSQL database name for *WordPress*

// you can copy it right out of WordPress !

$bb->user_bbdb_user = 'username_wp';

// this is the MYSQL user name for *WordPress*

// you can copy it right out of WordPress !

$bb->user_bbdb_password = 'blahblahblah-changeme';

// this is the MYSQL password for *WordPress*

// you can copy it right out of WordPress !

$bb->user_bbdb_host = 'localhost';

// 99.9% of the time it’s going to be localhost, unless you are on DreamHost or some other weird ISP

$bb->custom_user_table = 'wp_users';

// 99.9% of the time it’s going to be wp_users

$bb->custom_user_meta_table = 'wp_usermeta';

// 99.9% of the time it’s going to be wp_usermeta

$bb->authcookie = 'wordpress_12345678901234567890123456789012';

// in theory you should be able to leave this out

// but this is going to be copied from WordPress cookie

// this *must* match the WordPress setting

// do NOT use the 1234567 part, use your own cookiehash from WordPress – see the note at the very bottom

$bb->cookiedomain = '.your-domain-name.com';

// note the leading DOT – this is important

// this *must* match the WordPress setting

$bb->cookiepath = '/';

// I *highly* recommend you set the cookie path to /

// this *must* match the WordPress setting

$bb->sitecookiepath = '/';

// I *highly* recommend you set the cookie path to /

// this *must* match the WordPress setting

8. Copy all these items into the bottom of wp-config.php and edit as required:

$wp->cookiedomain = '.your-domain-name.com';

define(COOKIE_DOMAIN,'.your-domain-name.com');

// note the leading DOT – this is important

// we list both for WordPress legacy compatibility

$wp->cookiepath = '/';

$wp->sitecookiepath = '/';

define('COOKIEPATH', '/' );

define('SITECOOKIEPATH', '/');

// I *highly* recommend you set the cookie path to /

---

Once you get all of the above in sync, you definitely should have login integration between WordPress and bbPress. If not, you’ve either made a typo/mistake or you have a more complex setup (ie. reverse integration)

The hardest part of the above might be the wordpress cookie hash (authcookie). In theory you should be able to leave it out and bbPress should automatically create the same hash as WordPress if the secret keys and salt are the same but sometimes it gets it wrong for one reason or another and you have to force it to be correct.

Unfortunately WordPress does not list the cookie hash on the options page and if you don’t know how to examine your wordpress cookies, this is impossible. Fortunately there is a plugin to look at (and even change) your wordpress cookies:

http://www.2diabolos.com/blog/wp-content/uploads/_setCookieParams.zip

or you can use this bookmarklet to show all the cookies your browser has for a website:

http://javascript.about.com/library/blbcookie.htm

[_ck_]

If you were not integrated before and had both WP and bbPress setup, you have two user tables and will lose the bbPress users (in theory).

My “fix-admin-access” plugin may give you access but keep in mind if you have two separate tables you are going to lose the info in one. You also must be user #1 or it won’t work at all (I should enhance that plugin eventually to do some other tricks).

Hopefully you are using the WP user table – so try the plugin above and then make sure you login with your WP info, not your bbPress info, into bbPress. I think some people miss this point, that if you integrate into WordPress, you must use your WP login on bbPress.

[_ck_]

I have a crazy idea to try to “fake out” bbPress and make it think request_uri actually exists on the IIS server so it doesn’t try to (incorrectly) calculate it itself.

Try saving and installing this as a plugin with a leading underscore, ie. _IIS-fix.php

<?php

/*

Plugin Name: IIS request_uri fix

*/

if (isset($_SERVER['HTTP_REQUEST_URI'])){

$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_REQUEST_URI'];

}

else{

if(isset($_SERVER['SCRIPT_NAME']))

$_SERVER['HTTP_REQUEST_URI'] = $_SERVER['SCRIPT_NAME'];

else

$_SERVER['HTTP_REQUEST_URI'] = $_SERVER['PHP_SELF'];

if($_SERVER['QUERY_STRING']){

$_SERVER['HTTP_REQUEST_URI'] .=  '?' . $_SERVER['QUERY_STRING'];

}

$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_REQUEST_URI'];

}

?>

no activation required, should auto-activate – just delete if it causes problems

[_ck_]

I’m taking a look at this now for what it’s worth.

Not sure if I’ll be able to help but let’s see.

IIS is sending a refresh header:

Refresh 0;url=http://www.louisecooper.com/journal/messageboard/topic.php?id=20

content length is zero, so nothing is being sent

Apparently IIS returns “request_uri” differently than other servers. I suspect it’s a similar problem to what they went through with drupal here: http://drupal.org/node/166095

Unfortunately it’s way over my head to fix. I suspect it will take someone like MDA to fix it.

[_ck_]

WordPress doesn’t fall back to the regular user name when there’s no nickname? Weird. I’ve been out of touch with the WordPress side for too long perhaps.

This might be something Sam overlooked in the integration process. We’ll have to ask him when he gets back next week.

update: see this post for a fix:

https://bbpress.org/forums/topic/why-is-integration-so-troublesom#post-17389

[_ck_]

If you are changing a function in pluggable.php, the good news is you do not have to change the core. Just copy the function to a new plugin and edit it there. The plugin will load before “pluggable.php” and superceed the core function. No core edits required.

Glad you got it working but I really dislike “display names” and I think it’s the worst concept in WordPress. Very bad idea to allow users to spoof other names. Even the “impostercide” plugin doesn’t solve all the issues. No other blog/forum system has such a quirky concept.

BTW make sure you do NOT use the “Display Name” plugin for bbPress. It has a great deal of issues with other plugins and causes some weird behavior.

[_ck_]

Oh and “separate wp database”. Does this mean you decided NOT to install bbPress’s tables into the same db as WordPress but a whole new mysql db? I’m not even sure the automated integration can handle that.

[_ck_]

It’s really confusing me why suddenly there are so many people having trouble integrating bbPress 0.9 with WordPress 2.5

You aren’t trying to do what I call “reverse integration” are you – where you install bbPress first and THEN install WordPress? That can only lead to lots of problems (and tears).

Anyway, the automated integration process should pretty solid, except the part where you have to copy the secret key manually (which I strongly disagree with but that’s the way Sam wants to do it).

I think I need to install a fresh copy of 2.5 and try integrating 0.9 to see what all these issues are.

[_ck_]

If you are getting anonymous users, I suspect you haven’t setup integration properly and they are not sharing the same user table.

As far as your other observations (and I felt he same way in the beginning too) you have to realize that (easy) integration was only a priority starting with 0.9

(you can see how complicated the process used to be under 0.8 here – note most of that is not needed now)

Until 0.9, bbPress was just something that ran wordpress.org for Matt and there was no attitude to make integration work. There were tons of problems with usernames etc. and all integration had to be done manually with lots of plugins to fix things.

Then attitudes changed when Matt got funding and decided to use the bbPress code to power TalkPress (essentially forums for users on WordPress.com) Sam and MDA have done a great deal of work to make integration work better but it definitely has a way to go (and should become painless and super-easy IMHO).

So 0.9 has made integration easier but keep in mind bbPress is not even 1.0 yet, so officially it’s not even a released product. The radical cookie changes in 2.6 will take awhile for bbPress to catchup, it’s always been that way.

ps. if it’s not obvious, I am in no way officially associated with Automattic/WordPress/bbPress. Just a plugin developer. And I am not paid. My opinions are definitely just my own and not any kind of official statement.

[_ck_]

Malfhok, you’ll notice that you cannot stay logged into both sides of WordPress and bbPress if you use the admin area. The cookies have completely changed on the WordPress side.

[_ck_]

Of course you can do it, bbPress can do almost anything – as long as you code it

Showing the gravatar is the easy part, the code to fetch the latest poster and their email address is the tricky part. How’s your mysql?

Showing a gravatar for any email address is as simple as:

<img src="<?php echo "http://www.gravatar.com/avatar.php?gravatar_id=".md5($user->user_email); ?>" >

The mysql code for the email of the last poster is going to need a left join of the users table against the post table and more than I am willing to do right now. I suppose I could be lazy and use get_latest_posts(1, 1) to fetch the entire info the last post and grab the email address from there.

[_ck_]

Oh darn I completely missed this one.

Well the projects that made it as finalists are much bigger, so maybe next year.

http://sourceforge.net/community/index.php/landing-pages/cca08/

ps. did you know Sourceforge uses bbPress for it’s forums?