BuddyPress.org

Roy, what I think happened is that your activity tables were rewritten when you installed the most recent BP trunk. If you’ve been using the tagged version of 1.0.3 ( the one that is available via the big, orange download button) and not the trunk version of 1.0.3, then this is what happened.

In the newest version of BP, two of the original three activity tables are eliminated. Going forward, only one table is required. When you upgraded your live site to trunk, it eliminated two of the tables. When you reinstalled the earlier version (the tagged version 1.0.3) it reinstalled the two tables that were eliminated. But, they would have no data to display–at least at first.

Look at bp-activity.php in your 1.0.3 reinsall. Does the first line say thing?

define ( 'BP_ACTIVITY_DB_VERSION', '1300' );

Now, look at the bp-activity.php file from the most recent trunk (r1643 at the time of this post). Do you see the change in the schema-especially these lines of code?

/* Drop the old sitewide and user activity tables */

$wpdb->query( "DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_user_activity" );

$wpdb->query( "DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_sitewide" );

With the older version now reinstalled, and data being written back to the old tables, are you starting to see activity being reported in the widget?

Were you running 1.0.3 on your live site before this mess up? Or, where you running 1.0.2 or earlier?

The reason I ask is that the widget API changed in WP 2.8 and I believe Andy did not change to using the new Widget Class code in bp-activity-widgets.php until 1.0.3. So, are you sure that it was working before if you were using 1.0.3?

I should point out that the two tables that the latest trunk drops are not in my database even though I am running 1.0.3. Should I manually recreate the tables and see what happens? If I activated the 1.0.3 plugin it should have recreated those tables don’t you think?

You know, reading your question just made me realize the solution. I should have thought about this before–especially since I referred to it in my first post. For the activity table(s), this constant is what I indicated above:

define ( 'BP_ACTIVITY_DB_VERSION', '1300' );

The “1300” is the key. When you installed the trunk, the constant in bp-activity.php was set to this:

define ( 'BP_ACTIVITY_DB_VERSION', '1716' );

When BP needs to update any of its tables, it does so by incrementing a DB constant. When you log into WPMU’s backend as Site Admin, a routine runs and compares the DB version number in the DB with the one in the BP component code.

Since 1716 is greater than 1300, the update procedure ran when you installed the current trunk version. When you reinstalled (downgraded to) v1.0.3, since the constant stored in the DB was greater than the one indicated in the older version of bp-activity.php, the “upgrade” function did not run.

So, what you need to do is go into the wp_sitemeta table in the DBs backend, and search for the meta_key entry “bp-activity-db-version”. Change the meta_value number for that record to something lower than 1300. Then, log into WPMU’s backend as Site Admin. The upgrade routine will fire this time since 1300 will be greater than the artificial number you just entered. Your old tables will be reinstalled and your widget start working again!

Terrific! I’m glad I could help you out.

Jeff, thank you for your solution. I think I might be missing something minor.

Here is what I did:

I upgraded to Buddypress 1.1.1 and activity feed has gone missing as well.

Right now in bp-activity.php I have

define ( ‘BP_ACTIVITY_DB_VERSION’, ‘1800’ );

I searched the meta_key entry “bp-activity-db-version” and it was set to 1300.

Should I change that to something below 1300?

I set it to 1297, logged into wp-admin and hasn’t made a difference after initiating some activity.

Anyone a idea?

Thanks!

George

Suggest you make a new post; this one has been marked as resolved by its original author which is why many eyeballs aren’t looking at your post.