#22858 closed defect (bug) (fixed)
wp_update_user() does not check the return of get_userdata() before calling to_array()
Reported by: | ryan | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.5.1 | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Users | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
get_userdata() can return false, resulting in "Call to a member function to_array() on a non-object" when to_array() is called. This is triggered very rarely, but it does happen.
Attachments (2)
Change History (18)
#3
follow-up:
↓ 4
@
11 years ago
- Cc lukbarros removed
- Severity changed from normal to trivial
hi.
you can check return...
You should check your implementation as quoted in attached diff. Close this ticket that it does not proceed, will break several wp deployed when someone atualiazr and have implemented waiting for the return as false on failure.
#4
in reply to:
↑ 3
@
11 years ago
Replying to lukbarros:
You should check your implementation as quoted in attached diff. Close this ticket that it does not proceed, will break several wp deployed when someone atualiazr and have implemented waiting for the return as false on failure.
Hi lukbarros, I think you're saying that if we use user.diff, it will break plugins that expect a return as false on failure, rather than WP_Error. You have a point, for sure. But in this case, wp_insert_user() can already return WP_Error, and because of that, so can wp_update_user(). Both functions are documented to return a user ID on success and WP_Error on failure, and that's exactly what occurs now.
#7
@
11 years ago
Hello nacin there really is a point to be noted about the impact of change. Since users have other functions that return and the return of wp_erro should be adopted over time as the standard way to return errors and failures calls the core wp change is needed.
I still wonder what impact those implemented for plugins and routines that may await the return FALSE in case of no existence of the user with the id parameter for passaddo.
Who has the power to decide whether we change or not, giving acceptance to the possible?
#9
@
11 years ago
+1
We're keeping with the existing documentation that it will return the ID or an error. I support this change, and don't anticipate it will negatively affect many plugins.
That's why plugin authors test using release candidates, riiiight?
#10
@
11 years ago
In 1176/tests:
#11
@
11 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 23210:
hi.
you can check return