Opening the #weekly-updates thread for a brand new week; I hope yours has started off well. New to these?
Tag Archives: 5128
User last_activity data and BuddyPress 2.0
BuddyPress uses ‘last_activity’ data extensively: for display purposes (‘last active 3 days ago’), to sort results, and to determine whether a WP user is a valid site member. At the same time, ‘last_activity’ has been a perennial performance bottleneck. In the case of users, the information was stored in wp_usermeta
. This table gets exceptionally bloated on busy sites, and it’s not properly indexed for the sorts of ORDER BY
queries we were performing on it. See #5128 for more background.
A fix for this longtime issue is in place for BuddyPress 2.0. (See r7860.) Short version: user last_activity data is now stored in a ‘last_activity’ row in the wp_bp_activity
table. We’ve modified our core queries to take advantage of the new location. And we’ve done a bit of trickery to make sure that the wp_bp_activity
table is available for storage, even if the Activity component is disabled. The performance improvements are pretty extreme; I’ll post benchmarks as we near 2.0’s release.
Plugin developers who use user ‘last_activity’ data are urged to account for the new schema. In the past, you may have accessed user last_activity like this:
update_user_meta( $user_id, 'last_activity', $time );
$last_activity = get_user_meta( $user_id, 'last_activity', true );
You are urged to use our API functions instead:
bp_update_user_last_activity( $user_id, $time );
$last_activity = bp_get_user_last_activity( $user_id );
In cases where you are making direct database queries based on this info, please consider using BP_User_Query
instead. At the very least, you should refactor your queries to use the new schema.
For the time being, ‘last_activity’ data will continue to be mirrored in wp_usermeta
, so your plugins will continue to work. However, you’ll get deprecated notices every time you use the _user_meta()
functions to access the information. And hey, the new way performs much better, so you’ll want to update anyway.
Here’s a list of the plugins I found in the wordpress.org plugin repo that will need updating:
- bp-group-control
- bp-default-data
- welcome-pack
- activate-users-in-buddypress
- bp-groups-suggestions
- hts-display-active-members
- bp-member-widget
- buddypress-community-stats
- buddypress-sitemap-generator
- bp-ninja
Questions regarding this change? Need help migrating your code? Please leave a comment below.
(A quick note regarding ‘last_activity’ for groups and blogs. The basic problem there is the same as for users, but the scaling issues are much less severe, so they have not been touched for now. Keep an eye out for relevant updates.)
Once upon a time, we…
Once upon a time, we had #agenda posts going up once a week before the dev chat. They kind of died out when we switched the frequency and time of the dev chats around, but now that we seem to be on a bit of a roll again, I’d like to suggest we try something similar.
The goal is to put individual updates in a more visible place (finding the IRC logs is kinda tricky) and, by moving a lot of the updates to this site, to free up more time in the dev chats to give everyone more time to talk to each other synchronously and ask questions. If a feature developer has other time commitments for a particular meeting, moving the updates to the bpdevel site will make sure that everyone has the opportunity to read an update from them. Let’s see how this works for a couple of weeks, and we can make changes as necessary.
I’ll publish a #weekly-updates post on this site every week, and for everyone who’s contributing to a ticket, please leave a comment on that week’s update post with a summary of you’ve done. As a prompt when writing these: tell everyone what you contributed to last week, and what you’re aiming to do this/next week.