[apbai]

Are you running WP or WP MU?

I couldn’t find those in my wp-admin/options.php…

[JesperA]

Hmm, i think i´ve got it to work now, fingers crossed.

This is what i´ve changed from the original:

In bb-config.php:

define(‘BB_AUTH_KEY’, ‘hej’);

define(‘BB_SECURE_AUTH_KEY’, ‘hej’);

define(‘BB_LOGGED_IN_KEY’, ‘hej’);

define(‘BB_NONCE_KEY’, ‘hej’);

— removed by moderator —

The last 3 is find in wp-admin/options.php

And:

$bb->bb_xmlrpc_allow_user_switching = true;

[johnhiler]

You could write some Updates to make sure there was no ID overlap? That’s what I had to do when we were doing a similar user integration…

Actually – the user who wrote that last thread followed up with a fantastic list of exactly what steps s/he did, including specific update quries:

https://bbpress.org/forums/topic/successful-reverse-integration-steps

[gardenfl]

I’ve already considered the issues raised in that discussion. I looked at both user tables and it was clear that they would not line up without adding fields to the BBPress user table. There is also the problem of duplicate ids. Since almost all my users are forum members I could almost get away with dumping the WP user table and importing from BBPress. But then I would have the same problems discussed in that other thread. And I have members who have authored blog posts and forum entries.

[apbai]

Ha, you’re not alone. I had the same problem and just post my question a couple of hours ago!

[JesperA]

Hi!

I always have problem with the integration of BBpress and WordPress, i have installed bbpress integration in wordpress and stuff but still it doesnt work!

The cookies kinda works, when i login to WP i get loggedout of BBpress and vice versa!

Is it because i install it on localhost or something?

Couple of pictures, can anyone spot whats wrong?

wp-config:

http://farm3.static.flickr.com/2440/3834816298_90df119df5_o.png

bb-config:

http://farm3.static.flickr.com/2603/3834023401_f2f11b96d9_o.png

WordPress options in bbpress;

http://farm4.static.flickr.com/3430/3834023493_e10e719e75_o_d.png

bbPress options in WordPress:

http://farm3.static.flickr.com/2539/3834023615_27c8daed00_o.png

I really appreciate some feedback!

[johnhiler]

Something like this?

https://bbpress.org/plugins/topic/user-directory/

[apbai]

Right, I was not using WPMU. I did get the keys to match and also installed BBpress intergration plugin. There is only one line I was asked to add to wp-config.php:

define( ‘COOKIEPATH’, ‘/’ );

I added that too. But somehow it just doesn’t work:-(

[_ck_]

I’ve discovered that several of my plugins that have admin menus will not be able to access the admin menu in bbPress 0.9.0.7 and 1.0.3 because of the new admin menu security lockdown that was merged from WordPress 2.8.3 (essentially I didn’t go through the API for bbPress 0.8 compatibility).

I’ve now fixed what I can find but there will be other plugins with the same problem.

[_ck_]

I highly recommend people learn how to install bbPress (and wordpress) via SVN, it makes life incredibly easy. You can switch between bbPress versions in a heartbeat, test new betas or jump back to the previous version effortlessly.

See this topic for more info:

https://bbpress.org/forums/topic/svn-procedure-for-checking-out-bbpress

and my note at the end on how to install SVN as a simple client instead of the whole darn thing.

[_ck_]

Note that many plugins use their own tables to keep track of information based on topic_id and post_id because of the poor performance of bbpress meta (non-unique index and large string storage).

Currently there is nothing in the bbPress API that allows a plugin to hook to be notified when there is a topic_id or post_id change to an object. So all plugins in existence (and bbpress itself) assume this will never happen. The only thing bbPress accounts for is a forum_id change on a topic/post and I am not even certain there’s an API hook for that.

This means if you manually change a topic or post id, and you have plugins which store meta for those items, you’ve just broken your data in a way that cannot be rebuilt later. All the recounts in the world won’t fix the problem.

So keep that in mind. Things like attachments, polls, etc. are all affected by what you are talking about if those topics have such meta.

(this is also specifically why I tell people not to use the Move It plugin)

[gerikg]

Did you….

-have the Cookies & Salt all the same? example BBpress side define('BB_AUTH_KEY', 'ABCDEF'); WordPress side define('AUTH_KEY', 'ABCDEF');

-include $bb->bb_xmlrpc_allow_user_switching = true; in bb-config.php before the ?>

-install BBpress intergration plugin to get the Hash and cookie information to paste in wp-config.php after the < ?php ?

-Paste the same cookie information you did on the step before in bb-config.php (without the Hash line) after the < ?php ?

-Enable Pinbacks, trackbacks, and XML-RPC on BOTH WPMU & BBpress?

[johnhiler]

You definitely want to use the same users table for both installs.

I’ve had to eventually integrate bbPress and WordPress users after not integrating them upfront, and you definitely want to do it sooner rather than later. It wasn’t fun, but it’s definitely doable.

There’s a good discussion on how to go about it here:

https://bbpress.org/forums/topic/integration-of-established-wp-and-bbpress-installations

[gardenfl]

I eventually wish to use BuddyPress on a site, but feel I need to do this is stages.

At the moment this site consists of WordPress on one database and BBPress on a different database using the most recent versions of both scripts.

I started integration but stopped because I saw a potential problem.

I have about 70 registered users on BBPress

I have about 10 users on WordPress, these are mostly Authors.

I gave the users the same rank on both, making the WordPress Authors, Moderators on BBPress

Still, I suspect that I could be making a huge mistake if I don’t merge the User tables before integrating, and of course I would want everything setup correctly for interrogation before playing around with MU and BuddyPress.

Now if I understand this correctly the User table for an integrated site should be WordPress, not BBPress?

Is there such a thing as a script that would allow me to make all BBPress users WordPress users?

Or am I looking at this all wrong?

Or is it possible to set up MU/BuddyPress and merge all users onto that?

[apbai]

I have installed the latest wp and bbpress with cookie integration enabled. But it seems not working. If log in from wp, bbpress account is automatically logged out. Same thing the other way around. What could be wrong? I believe I set all the keys correctly.

[usera]

nevermind. seems the objects are overly generic. i’ll have some patch it up to work.

[usera]

I think you may be confused _ck_. memcache has it’s uses like php op_code. It does not take alot for it to have a benefit and the same applies to memcache. However I am not asking for a suggestion on avoiding memcache. I would like to see a better handling of objects in the same way you create a prefix for a database. If you set a large pool for memcache say 1gb. The idea of setting another instance and monitoring it with startup script gets a little bothersome especially when an array can be used to mitigate the possibility of one failed instance to drive your site down. In short I should say you don’t usually start another mysql to house a database nor would it be useful to do that with memcache.

Thanks samhaurs again. I just want to be sure there weren’t objects that are generically named that can be seen across bbpress installations like administrative or personal details that should be separate that some are improperly written to cache much like wordpress mu does at the moment.

[_ck_]

Because of mysql replication, using the mysql cache is probably impossible on wp.com

Once you move beyond a single mysql server, things get complicated fast.

But that’s specifically the environment memcache was written for, not single server systems.

(by the way, how large is the wp.com memcache pool? I bet it’s massive)

However I find the MySQL cache has not been turned on for many VPS/dedicated servers. That’s a performance showstopper and makes a huge difference when the same queries are being done over and over on a typical bbPress install. A PHP opcode cache is the next largest performance improvement.

Here is the typical breakdown for MySQL vs Memcached performance:

Cache Type 	 Cache Gets/sec  (higher is better)

Array Cache  		365000              (this is local memory, fastest possible)

APC Cache 	 	98000                        (this is common memory via apc/eaccelertor/xcache)

File Cache  		27000                        (this is using the local disk cache)

Memcached Cache (TCP/IP) 	12200     <<<<====---

MySQL Query Cache (TCP/IP) 	 9900

MySQL Query Cache (Unix Socket)  13500    <<<<===---   (local mysql server, with cache)

Selecting from table (TCP/IP)	 5100             (remote mysql server, no cache)

Selecting from table (Unix Socket)  7400     (local mysql server, no cache)

[Sam Bauers]

“[WordPress.com] uses several dozen queries per page load.”

Thanks to memcache the average blog front page on WordPress.com uses only a handful of queries, sometimes as few as one.

“It absolutely cannot just rely on the mysql cache, even with dedicated mysql servers.”

From memory, WordPress.com doesn’t use MySQL query cache at all as it would need to be invalidated many times every second. We also would need to invalidate all slaves as well as the masters.

I think it’s important to say that you should only setup and enable any caching if you actually need it. Most people don’t and shouldn’t, all you do is add another potential point of failure into your site.

[_ck_]

Let’s review this from scratch.

WordPress and bbPress 1.0 has what we call an object cache. That is simply a pool of users, forums,topics, and posts and meta as they are passed between mysql and the application (wordpress/bbpress). It’s just another layer between mysql and bbpress.

Typically these “objects” are lost after every page load because they are no longer in regular short-term computer memory and have to be fetched again from mysql.

On a single computer system with a fast mysql server and fast disk cache, this typically is not a big problem. As a site has to scale this does become a problem because there is only one mysql source and everything has to be fetched from it.

Using a poorly configured WordPress or bbPress system with badly written or improperly running plugins, if each page load requires 30-40 queries, and you have 1000 users connected simultaneously at once, that’s a huge problem.

Memcache is a common pool of memory that doesn’t go away after each page load. It’s centralized on one server so multiple servers can all find it easily. It was invented by LiveJournal after they hit a growth limit with mysql.

The Memcache to Object Cache interface plugin for WordPress/bbPress 1.0 allows the fetching from mysql to be skipped IF the user/forum/topic/posts happen to be in the previously accessed pool in that centralized memory. Every time a query is made, the resulting data is saved in the collective memory which is retained inbetween page loads. It’s a common, shared memory.

However Memcache was written to talk over tcp/ip between MULTIPLE servers. For a single server setup it’s pointless and stupid and way too much overhead.

Now, on a single server, you could still use a persistent object cache with one of the other lesser known plugins that mimic what the memcache interface does. There is one for Eaccelerator, one for APC and one for Xcache.

However, all of these caches do almost the same thing as MySQL’s cache. They are all tied to the particular kind of query that is done and if it matches the previous set of data. The object cache still has to de-serialize data if it’s serialized.

MySQL on a single server system does not use tcp/ip to communicate with bbPress if it’s properly configured (and most are unless your host is greedy and stupid and uses a central mysql server separate from your regular server). So MySQL with a properly configured cache is almost as fast on a single server setup than a persistent object cache (unless MySql is overloaded in the first place).

So in conclusion, if you are on a shared host, object caching is not a viable solution for you because you can’t get any of the persistant memory options installed anyway. If you are on a single server setup but not dealing with a large number of connections, the mysql cache is probably going to be near the performance of a persistent object cache, and the real memcache would never be used in the first place.

Memcache was meant for large, inefficient installs like WordPress.com

WP.com serves many thousands of people simultaneously from many different servers. It uses several dozen queries per page load. It absolutely cannot just rely on the mysql cache, even with dedicated mysql servers. The average wordpress/bbpress user does not face these problems typically.

If you have your own VPS or dedicated server you should be installing an opcode cache like Eaccelerator, APC or Xcache and turning on the shared memory pool option (typically during compile). Then you should make sure your mysql cache is ON and setup properly. Then you should make sure your pages are not using too many queries. If you’ve done all that and you have so many simultaneous visitors that your mysql is running too high a load and your pages are still too slow, then you can look at one of the persistent object cache modules for wordpress and port them to bbpress.

None of the bbPress installs in the Top 10, are using memcache or any kind of object cache for that matter (including wp.org which is using bbPress 0.9). So I sincerely question the need of anyone else using an object cache just yet unless they have made their install extremely inefficient somehow or have a horrible host.

[m3i zero]

good news,have a try

[Ryan Hellyer]

Hmm, showing my total ignorance of caching here …

I assumed memcaching was the best way to improve the performance of bbPress and WordPress on a server even if it was only on a single server. So if I have a VPS, what specifications should I request to make sure it runs at maximum efficiency?

I”ve been contemplating moving to a 512 MB VPS and requesting they install mem cache on it for me. But juding by _ck_’s comments above that would be a stupid thing to do.

Any opinions?

[Sam Bauers]

@usera

You can setup a new memcached instance to avoid clashes with wordpress, but if you are sharing user tables then it shouldn’t matter.

If you add another memcached instance on a different port you can point bbPress to it by adding this to bb-config.php (default IP and port shown here)…

$memcached_servers = array( 'default' => array( '127.0.0.1:11211' ) );

[_ck_]

Memcache is only useful for multi-server installations otherwise it has too much overhead.

Eaccelerator, APC and Xcache have shared memory solutions that are significantly faster than memcache on a single server setup. But on a single server, it’s also been demonstrated a proper mysql cache can be faster than an object cache in some cases.

Eaccelerator, APC and Xcache can already store server session data in shared memory, you just have to compile with the option and turn it on in PHP.

There are plugins for wordpress that could be ported to bbPress 1.0 for the object cache but IMHO it’s a waste of time unless you have a very slow or overwhelmed mysql server.

[Olaf Lederer]

right no session at all

@rareexample, just use the cookies created by bbpress (using firefox it’s easy to discover the cookies)