[buddypress-trac] [BuddyPress Trac] #5128: Move user and group last_activity out of wp_usermeta

buddypress-trac noreply at wordpress.org
Mon Feb 3 16:15:19 UTC 2014

#5128: Move user and group last_activity out of wp_usermeta
 Reporter:  boonebgorges                         |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  high                                 |   Milestone:  2.0
Component:  Core                                 |     Version:
 Severity:  major                                |  Resolution:
 Keywords:  has-patch needs-testing 2nd-opinion  |
Changes (by boonebgorges):

 * keywords:  has-patch needs-testing => has-patch needs-testing 2nd-opinion


 Thanks very much for having a look, imath.

 > Because afer applying the patch, the user having the usermeta but not
 the new activity type won't be listed in the members directory
 (last_active filter)

 If this didn't work for you, it's a bug in the patch. I have a migration
 routine already in place. See the bp-core-update.php section of the patch:
 It should run on 'bp_admin_init' - maybe you never loaded the admin? Load
 the admin page (as you would if you were upgrading the plugin to 2.0) and
 see if it works for you.

 > The problem will only happen if the plugin is using a custom query or
 (bp_)get_user_meta function.

 Correct. This is the case I'm worried about. I've just done a quick search
 through plugins.svn.wordpress.org, and found the following plugins are
 making direct calls to usermeta for 'last_activity':
 - 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

 This is actually a larger number than I'd feared. Some of these plugins
 are outdated, but I'm sure they're still in use by many, and it suggests
 that there are many unreleased plugins/hacks that are doing something
 similar. It says to me that we should mirror for a version or two, with a
 big obnoxious _doing_it_wrong() notice for incorrect usage. The
 deprecation checks would look something like this:

 1. When calling `update_user_meta( $user_id, 'last_activity' )`, mirror
 the data to the activity table, and throw a _doing_it_wrong() message
 2. When calling `get_user_meta( $user_id, 'last_activity' )`, return the
 data from the activity data instead of usermeta, and throw a
 _doing_it_wrong() message
 3. In `bp_update_user_last_activity()`, set the last_activity usermeta.
 4. Filter 'query', and do a search for {$wpdb->usermeta} and
 'last_activity'. If found, throw a _doing_it_wrong() message

 Number 4 is worrisome because I don't know what kind of overhead it will
 add. However, it could be important, because many of the plugins listed
 above are making direct queries that won't get notices any other way.

 We could include this stuff for, say, one or two major versions, and then
 remove it. This, along with a big publicity push on bpdevel.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5128#comment:9>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list