Archive for the ‘Uncategorized’ Category

WPMu, BuddyPress, bbPress integration

Ok, so I had to sort out why bbPress and WPMu weren’t integrating. My client was pulling out his hair, and I just didn’t think the bald look would suit him.

First off, let’s not repeat what is being said repeatedly all over the internet on forums and blogs. Start here, this is a good guide to getting integration done.

Once you’ve done that you may be lucky and things will just work – it seems to work for some and not for others.

However, if it doesn’t here’s a list of the things I did to make it work.

Add this line to the end of both your wp-config.php and bb-config.php files;

define( ‘WP_AUTH_COOKIE_VERSION’, 1 );

It looks like WPMU (2.7.1) may already be using version 2, so that’s why it seems to be necessary to explicitly tell both WPMu and bbPress which version to use.

Next, make SURE that your KEYS and SALT VALUES match up. KEYS are set in the wp-config.php and bb-config.php files, SALT VALUES are set in wp-config.php and http://[your blog site]/[bbpress location]/bb-admin/options-wordpress.php.

Next thing may be a bit odd – and most likely this isn’t the most secure way of doing it (the preferably way would be to figure out why WPMu isn’t attaching the HASH value to the cookie name), but, in wp-config.php set COOKIEHASH to an empty string like so;

define( ‘COOKIEHASH’, ” );

And in bb-config, set BB_HASH to an empty string as well – like so;

define(‘BB_HASH’,”);

Remember to test every step of the way – your integration could start working at any point!

However, if all the above has been done and it’s still not working, there’s an edit required in the bbPress code, and another line to be added to bb-config.php which sorted it out for me (and ensured my client of a beautiful head of hair). And here it is!

Add this line to bb-config.php:

$bb->wp_cookie_path = ‘/’;

And on line 928 of bb-settings.php (bbPress version 1.0.1) after this line;

unset( $_plugin_cookie_paths, $_type, $_data, $_cookie_path );

Add this;

if ( $bb->wp_cookie_path ) {
	$cookies['auth'][] = array(
		'domain' => $bb->cookiedomain,
		'path' => $bb->wp_cookie_path,
		'name' => $bb->authcookie
	);

	$cookies['secure_auth'][] = array(
		'domain' => $bb->cookiedomain,
		'path' => $bb->wp_cookie_path,
		'name' => $bb->secure_auth_cookie,
		'secure' => true
	);
}

Basically, after much digging, I noticed that when you log in via bbPress a cookie value is missing, so that just makes sure that it’s there.

If all goes well you should now have an integrated site using WPMu, BuddyPress, and bbPress.

If it’s still acting up, make sure you clear your cookies for the relevant domain (or just all cookies if you like) – actually – do that anyway to be on the safe side.

You’ll notice I don’t mention anything about BuddyPress, that’s cos it seems to work for me as soon as I’ve done what I explained in this post.

Lastly, I’m sure there are better (and right) ways of doing what I’ve done, and that this is possibly a hack rather than a proper fix. I’ll send a link of this post to the bbPress guys tho, so hopefully this will be of some help to them and they’ll know how to sort it out more elegantly.

Good luck!

WP E-commerce coolness

I was pretty damn pleased with myself this week when I managed to track down a performance error that’s been causing everyone using Instinct‘s e-commerce plugin gray hair for some time now. Lucky for me the first plugin I wrote (which I’ve yet to polish and publish), I based on this plugin (as I had no clue about how to go about writing a plugin), and ran into the same problem. Eventually, whilst working on the survey plugin (which I’ve yet to polish and publish ;P) I came across the solution, although I didn’t realize at the time that this would also help with the e-commerce plugin.

So this week Ashley was pulling out his hair due to the fact that the plugin was causing the latest fossil-line (that’s worse than a deadline) project to constantly crash and asked me to have a look. After buggering about for a while I suddenly remembered what I described above, implemented it, and suddenly it was all better! Pretty cool huh?

Well, everyone else thought so too (he says modestly).

So here’s the solution for all those who have been salivating for it whilst having to read through all my crap :

search for

add_action(‘init’, ‘nzshpcrt_install’);

and

add_action(‘init’, ‘wpsc_auto_update’);

and replace it with

register_activation_hook(__FILE__, ‘nzshpcrt_install’);

and

register_activation_hook(__FILE__, ‘wpsc_auto_update’);

respectively.

Alternatively, although I’ve not tested this, I think the if statement is just seriously flawed and should look like this:

if(isset($_GET['activate']) && ($_GET['activate'] == 'true')) {
	if(($current_version_number < WPSC_VERSION ) || (($current_version_number == WPSC_VERSION ) && (get_option('wpsc_minor_version') <= WPSC_MINOR_VERSION))) {
		include_once("install_and_update.php");
		add_action('init', 'wpsc_auto_update');
	} else {
		include_once("install_and_update.php");
		add_action('init', 'nzshpcrt_install');
	}
}

In the event of using this if statement either register_activation_hook or add_action('init',...) should work fine.

Enjoy!

Archives