#7112 closed defect (bug) (fixed)
xprofile field cache is stale after update
Reported by: | emrikol | Owned by: | dcavins |
---|---|---|---|
Milestone: | 2.6 | Priority: | normal |
Severity: | normal | Version: | 2.4.0 |
Component: | Extended Profile | Keywords: | has-patch commit |
Cc: |
Description
After running BP_XProfile_Field::update_position()
(from a drag and drop move in /wp-admin/users.php?page=bp-profile-setup
for example) the object cache is not updated or cleared for the field and subsqeuent calls to xprofile_get_field()
will return old data.
I'm able to reproduce this by:
- using a persistent object cache
- dragging and dropping fields around in the editor from one group to another
- refreshing and the fields act as if they've not moved groups
- flushing the object cache and refreshing the editor page
- viewing the fields have moved to the new groups they should be assigned to
This is the temporary fix I've been using to address this problem:
--- a/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-field.php +++ b/plugins/buddypress/bp-xprofile/classes/class-bp-xprofile-field.php @@ -940,6 +940,9 @@ class BP_XProfile_Field { $sql = $wpdb->prepare( "UPDATE {$table_name} SET group_id = %d WHERE parent_id = %d", $field_group_id, $field_id ); $wpdb->query( $sql ); + // Clear old field cache + wp_cache_delete( $field_id, 'bp_xprofile_fields' ); + return $parent; }
Attachments (2)
Change History (14)
#5
@
8 years ago
- Component changed from API to Component - XProfile
- Keywords needs-unit-tests added
- Version changed from 2.5.0 to 2.4.0
Thanks for reporting, emrikol.
Patch looks good at a glance. We'll add some unit tests before committing a fix for this.
Also, see #6638 where we introduced xprofile field caching.
#6
@
8 years ago
- Keywords has-patch added; needs-unit-tests removed
01.patch
adds a unit test for this problem; emrikol's patch works.
Maybe we can sneak this in for 2.6?
#7
@
8 years ago
Thanks, @r-a-y! Can we test that the position is reported as updated instead of the cache being empty, since that's the underlying action? The cache causes the attached test to fail, also. I'm not sure what level is the place to test. :)
#9
@
8 years ago
- Keywords commit added
- Milestone changed from Awaiting Review to 2.6
Thanks for the report, @emrikol.
Fix looks good. The test in 7112-alt-test.diff is probably better; we should avoid directly referencing the cache in tests, in case we decide to change the implementation later on. What we really care about is that the data is invalidated, which we can only know by pulling up a new object.
#11
@
8 years ago
- Owner set to dcavins
- Resolution set to fixed
- Status changed from new to closed
In 10877:
Hi @emrikol-
Thanks for your report and detailed steps to reproduce! What version of BuddyPress are you seeing this with?