Skip to:
Content

BuddyPress.org

Opened 2 years ago

Closed 2 years ago

#7595 closed defect (bug) (fixed)

Use WP_User::get_data_by in BP_Core_User::get_core_userdata (remove custom user object cache)

Reported by: johnjamesjacoby Owned by: johnjamesjacoby
Milestone: 3.0 Priority: normal
Severity: normal Version: 1.2
Component: Members Keywords: has-patch commit
Cc:

Description

The method & approach in BuddyPress now is a relic from before WordPress had a reliable way to just get a user object (without caps & meta.)

BP_Core_User::get_core_userdata() currently calls a raw database query to wp_users to get a user from a $user_id, which bypasses cache entirely. Custom user object caching is done inside of bp_core_get_core_userdata(), instead of using what's already provided by WordPress.

By trusting WP_User::get_data_by() instead, BuddyPress becomes less complex by eliminating an entire cache layer, and its userdata is guaranteed to be inline with WordPress and any plugins that might be calling wp_update_user() on their own.

Performance improvements on a bbPress installation are pretty impressive. Forum sections with fully populated and paginated forums & topics can see a 30+ query reduction, with an equivalent improvement for cache misses.

The only caveat is that we'd need to remove the "user not found" caching that was added in r11611. FWIW, I think this is fine. I think if we want to handle the caching of missing users/objects, we should probably recommend a patch upstream to WordPress core to handle this more elegantly for all missing objects.

Patch imminent.

Attachments (1)

7595.diff (4.4 KB) - added by johnjamesjacoby 2 years ago.

Download all attachments as: .zip

Change History (6)

@johnjamesjacoby
2 years ago

#1 @johnjamesjacoby
2 years ago

we should probably recommend a patch upstream to WordPress core to handle this more elegantly for all missing objects

It's worth noting that the Options API does this with a notoptions cache. It's weird and unique, but it solves this exact problem in a way that probably shouldn't be as unique as it is.

#2 @r-a-y
2 years ago

The only caveat is that we'd need to remove the "user not found" caching that was added in r11611.

I'm fine with this. Currently, with the exception of private message content, deleted users do not have their data kept in the DB.

Let's go with JJJ's patch for now.

Last edited 2 years ago by r-a-y (previous) (diff)

#3 @DJPaul
2 years ago

  • Keywords commit added
  • Milestone changed from Awaiting Review to 3.0

Looks great. Can you commit, @johnjamesjacoby?

#4 @johnjamesjacoby
2 years ago

  • Keywords 2nd-opinion removed
  • Owner set to johnjamesjacoby
  • Status changed from new to assigned

#5 @johnjamesjacoby
2 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 11705:

Members: trust WP_User::get_data_by() and eliminate an additional user cache layer.

This change removes ye olde bp_core_userdata_ cache key system, relying 100% on the baked-in object cache for user data and improving the liklihood of cache hits (particularly when other membership or community plugins are looking for user data outside of a BuddyPress specific context.)

For example, bbPress will look for authors of topics and latest posts on various forum pages, but BuddyPress will want to make sure it's XProfile Field display names are used. Previous to now, BuddyPress would need to re-query for these users and keep a separate cache of them. By relying on the traditional user objects, those duplicate database queries never happen, resulting in much joy.

This additionally improves page performance throughout the entire application. When user accounts are updated (via XProfile or related) and then immediately prime their caches, there is no more secondary BuddyPress-specific user object cache to prime.

Fixes #7595.

Note: See TracTickets for help on using tickets.