Opened 11 years ago
Closed 9 years ago
#24635 closed enhancement (fixed)
update_user_caches() should support accepting a WP_User instance
Reported by: | dd32 | Owned by: | |
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Users | Keywords: | has-patch needs-unit-tests |
Focuses: | Cc: |
Description
At present update_user_caches($user) blindly stores the value from $user into the object cache.
Although core only ever passes the raw data from wp_users
into this function, due to the naming of it, and the phpdoc, plugin devs may pass a WP_User instance to the function.
The result is that a WP_User instance is stored within the object cache rather than stdClass of a wp_users
row as expected.
For most intents this causes little issue, the function and cache still work, so the developer will see no side effects.
But this has the cause that when that user's data is retrieved from the cache, the original WP_User object is restored -- including all meta keys that were stored in it, If one of those meta keys is a serialized object which calls a not-yet-loaded function, it can cause the request to fatal error. It's a pretty specific issue, but can simply be avoided by never storing a WP_User instance in the cache.
Attached patch simply tests for the data and acts appropriately. mostly untested.
Attachments (1)
Change History (13)
#2
@
11 years ago
- Keywords 3.7-early added
- Milestone changed from Awaiting Review to Future Release
- Version changed from trunk to 3.0
#6
in reply to:
↑ 5
@
11 years ago
- Keywords needs-unit-tests added
- Milestone changed from 3.7 to 3.8
Replying to ryan:
Is $user = $user->data necessary?
Yeah, that's the operative part of the patch. It's the underlying stdClass DB row that we want to store in the cache.
This needs tests, I'd say.
PHPDoc untouched, Worth noting that clean_user_cache() accepts
int|WP_User
, which is why both of those branches were added to this function.