Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 11 years ago

#5098 closed defect (bug) (fixed)

bp_settings_action_general() misses to invalidate object cache

Reported by: wpdennis's profile wpdennis Owned by: boonebgorges's profile boonebgorges
Milestone: 1.9 Priority: normal
Severity: normal Version: 1.7
Component: Members Keywords: dev-feedback has-patch needs-testing
Cc:

Description

If a user changes his email adress under /settings/general/ it gets changed in the database but the GUI shows the old email adress.

This occurs with an enabled object cache. The reason seems to be, that bp_settings_action_general() just uses wp_update_user() but doesn't invalidate the BP specific cache key "'bp_core_userdata_' . $user_id".

But bp_core_get_core_userdata() is used to show the value of the email input field. And bp_core_get_core_userdata() loads the value of "'bp_core_userdata_' . $user_id" from object cache.

Maybe this would solve the problem:

// Make sure these changes are in $bp for the current page load
if ( ( false === $email_error ) && ( false === $pass_error ) && ( wp_update_user( $update_user ) ) ) {
    wp_cache_delete('bp_core_userdata_' . bp_displayed_user_id(), 'bp'); // ADDED LINE
    $bp->displayed_user->userdata = bp_core_get_core_userdata( bp_displayed_user_id() );
}

Do you see any issues with this or am I missing something?

Attachments (1)

5098.01.patch (2.2 KB) - added by r-a-y 11 years ago.

Download all attachments as: .zip

Change History (5)

#1 @boonebgorges
11 years ago

  • Keywords has-patch needs-testing added
  • Milestone changed from Awaiting Review to 1.9

This looks pretty good at a glance. Moving to 1.9.

@r-a-y
11 years ago

#2 @r-a-y
11 years ago

Instead of explicitly calling wp_cache_delete(), 01.patch adds a second parameter to bp_core_get_core_userdata() to requery the userdata and resets the userdata cache.

Same idea as wpdennis basically, but offers more flexibility.

#3 @boonebgorges
11 years ago

As we discussed a few weeks ago, I think that the $requery param misses the mark. The bug here is not that the data needs to be requeried, it's that the cache should be (but isn't being) deleted - and *that*, in turn, will cause another query. wpdennis's solution seems to strike more at the heart of the issue.

#4 @boonebgorges
11 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 7586:

Delete core_userdata object cache when updating settings

When updating settings, the settings are sometimes saved on the same pageload
as the settings page is displayed. To ensure that the current pageload's fields
reflect just-changed settings, the persistent object cache key for the saved
settings must be manually busted just after a successful save.

Fixes #5098

Props wpdennis

Note: See TracTickets for help on using tickets.