wp_update_user() does not check the return of get_userdata() before calling to_array()

[ryan]

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.

[lukbarros]

hi.

you can check return

[lukbarros]

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.

[nacin]

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.

[SergeyBiryukov]

With proper formatting

[lukbarros]

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?

[georgestephanis]

+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?

[nacin]

In 1176/tests:

Test that wp_update_user() does not fatal error when called with a non-existent user ID. It should instead return WP_Error. see #22858.

[nacin]

In 23210:

Return WP_Error from wp_update_user() on a non-existent user, avoiding a fatal error in the process.

props n7studios, SergeyBiryukov.
fixes #22858 for trunk.
Unit tests: [11776/tests].

[nacin]

In 23211:

Return WP_Error from wp_update_user() on a non-existent user, avoiding a fatal error in the process.

Merges [23210] to the 3.5 branch.

props n7studios, SergeyBiryukov.
fixes #22858.

[nacin]

In 23225:

Switch to a string already available in the wordpress.pot, via the XML-RPC server class. The other string is only available in the wordpress-admin.pot.

Prevents any string movements in the 3.5 branch. see #22858.

[pavelevap]

But 3.5 branch in GlotPress was influenced? There are 2 similar strings now: "Invalid user ID" and "Invalid user ID."

[SergeyBiryukov]

#23005 was marked as a duplicate.