I figured out the problem was because I was using the file based caching that the BP developers recommended here: http://codex.buddypress.org/getting-started/improving-performance/. They might want to rethink recommending something that creates such a big problem! Unless you are going to turn off private messaging, you can’t use that. I’ve gone back to WP-Super Cache (with caching turned off for logged in users) and that seems to work OK.
I’m seeing this as well, and I’ve even seen it happen when our caching system was turned off. Could you provide a few more details as to what modules are involved or how the file caching triggers this as I would definitely like to find a way of fixing this.
Well I don’t know if this a bug or not, but I found (almost) the root of the problem and a relatively simple fix.
I discovered that the recipients table had entries for threads that were not in the messages tables. I don’t know where these threads came from, but they were definitely there. So I changed the messaging code to generate the thread_id from the recipients table rather than the messages table.
If this was some sort of database corruption, this was a reasonable fix for me. We don’t have enough messages for it to be a performance issue and if something else is inserting into that recipients table we shouldn’t conflict with it (assuming it is generating thread_ids in the same way).
I really don’t know enough about BuddyPress to know if this is a core bug or some other issue related to our theme (I can’t find any other references to that table so it’s kinda wierd).
bp-messages-classes.php:
/* If we have no thread_id then this is the first message of a new thread. */
if ( empty( $this->thread_id ) ) {
$this->thread_id = (int)$wpdb->get_var( $wpdb->prepare( “SELECT MAX(thread_id) FROM {$bp->messages->table_name_recipients}” ) ) + 1;
$new_thread = true;
}
I’m having this same problem; I don’t know how it started, but threads are getting assigned IDs for deleted threads where the recipients are still in the database (same problem that was found in this trac entry http://buddypress.trac.wordpress.org/ticket/3971)
I don’t really want to hack the core to fix it, I’d rather just do a SQL query to delete any recipients for threads that don’t exist. Are there any caveats in doing this?
Ooh, I just discovered that all the old messages don’t have a thread assigned, but they should! This happened during an upgrade from a much older version… I wasn’t involved in that process, so I don’t know quite what happened. I think I can reassign the messages their thread number by looping through the thread message_ids… Is it possible to do that with a SQL query or do I have to use PHP to get the IDs out of the array?
This must be why the new messages started assigning low value thread numbers. Does the new thread take it’s ID from the thread table or the messages table?
and send a message to them. However, A’s name will still be listed there instead of B’s. If you don’t notice this and type in B’s username, then your message will wind up sending to BOTH A and B. The only way you can get rid of A’s name from showing up is if you go back to YOUR profile and send a message from there.
