Opened 14 years ago
Closed 10 years ago
#20043 closed enhancement (fixed)
WP_User missing magic __unset() method
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 4.4 | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Users | Keywords: | has-patch |
| Focuses: | Cc: |
Description (last modified by )
When the magic methods were put into WP_User in 3.3, __unset() was skipped. This has the result of unset( $user_data->$foo ); not actually doing anything.
Patched against r19926.
Attachments (4)
Change History (21)
#5
@
14 years ago
In here would work: http://unit-tests.trac.wordpress.org/browser/wp-testcase/test_user.php#L140
#8
@
13 years ago
- Milestone changed from Future Release to 3.6
Patch and unit test. Moving into 3.6 for consideration.
#9
@
13 years ago
I'm fine with this, but what's the use case? Other than a change in behavior from a year ago. I'm curious because I'm not sure we should easily allow the unsetting of core properties if we can avoid it. (Doesn't matter, just playing devil's advocate.)
#11
@
10 years ago
- Keywords needs-refresh added
- Milestone changed from Future Release to 4.4
- Owner set to chriscct7
- Status changed from new to assigned
- Type changed from defect (bug) to enhancement
#12
@
10 years ago
- Keywords needs-refresh removed
refreshed/combined - not entirely sure how necessary this is
#14
@
10 years ago
- Keywords needs-docs added
- Resolution fixed deleted
- Status changed from closed to reopened
- Needs an access-modifier
- Needs complete docs
#16
@
10 years ago
- Keywords needs-docs removed
- Resolution fixed deleted
- Status changed from closed to reopened
[34380] is causing errors in the test_user_unset_uppercase_id() test introduced in the same changeset. What's happening is this:
__unset()unsets$user->ID- The test then attempts to access
$user->ID. Since the property no longer exists (! isset( $user->ID )), the magic__get()kicks in. __get()tries toget_user_meta( $this->ID, 'ID', true ). But$this->IDis an undefined property.
Unsetting an object property like ID is going to cause similar problems through core and elsewhere. Either we should have a blacklist of properties that cannot be unset (so unset( $user->ID ) would return false), or unset( $user->ID ) should just empty the property ($user->ID = 0).
Well, since we have
__set(), I guess it's fair to have__unset()too.