get_user_meta($user_id); returns serialized values in second level array

  • I’m using get_user_meta(); And it returns something in the style of

    [user_meta]
    [metakey]
        [0] => "Serialized value here"

    Now from my feeble understanding this seems to be intended behavior since in get_metadata
    there is these lines:

    if ( !$meta_key )
		return $meta_cache;

    that are right before the maybe_unserialize:

    if ( isset($meta_cache[$meta_key]) ) {
		if ( $single )
			return maybe_unserialize( $meta_cache[$meta_key][0] );
		else
			return array_map('maybe_unserialize', $meta_cache[$meta_key]);
	}

    So depending on if a key is specified, get_metadata will return (possibly)serialized or unserialized values.
    Is there a reason for this that I’m not catching?

Viewing 7 replies - 1 through 7 (of 7 total)

  • Put use print_r() to output your usermeta data and post that output or to the pastebin if it is more than ten lines. Obfuscate anything potentially sensitive– login name, that kind of thing.

    Thread Starter Stéphane Boisvert

    (@sboisvert)

    Hi s_ha_dum,

    Here is a shortened version of the array that shows the problem:

    https://pastebin.com/Bk6BWNE6

    you’ll notice the key wp_1_capabilities
    it is still serialized. Now if I were to call the function
    get_metadata(‘user’,1,’wp_1_capabilities’)
    instead of
    get_metadata(‘user’,1)
    I would get that value unserialized.

    I’m just wondering if I’m missing a logical reason for why this is the way it is or if it would be something that people would be open to changing the logic so that all the meta comes back unserialized all the time.

    Moderator bcworkz

    (@bcworkz)

    I think the reasoning is just to provide different options for programmers. Same reasoning as providing an output type argument for many functions. I prefer unserialized, but some one may prefer serial data. That person may be unhappy if their option were removed. Not to mention existing implementations would break if the format were changed. Since it’s trivial to change between the formats, I can’t see any good reason to change.

    You would add significant overhead if you tried to maybe_unserialize(...) all of get_usermeta(...). That can be a sizeable chunk of data. If you are only pulling one part, as in get_metadata('user',1,'wp_1_capabilities') the overhead is minimal. I imagine that is the logic. There may well be other reasons, and legacy reasons as well, as bcworkz suggested.

    Thread Starter Stéphane Boisvert

    (@sboisvert)

    Thank you to both for your comments. I guess what I am trying to say is why is it not already in an unserialized format by this point. I completely agree and have noticed that maybe_unserialize adds great amounts of overhead.
    I guess what I am trying to say is shouldn’t wp_cache_get() return an already unserialized array so that the unserialization only happens once?

    Thread Starter Stéphane Boisvert

    (@sboisvert)

    I guess I should also note that from my understanding, if we pass these values unserialized to apc and xcache they will come back unserialized. Of course Thinking about it, perhaps this falls under the purview of the role of the object caching plugins job?

    wp_cache_get() does not, by default, create a persistent cache. The unserialization would have to be done at least once per page load. That could still be unnecessary overhead. Persistent caching requires a plugin.

    …if we pass these values unserialized to apc and xcache…

    These are not installed on all servers. WordPress cannot count on having them available.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘get_user_meta($user_id); returns serialized values in second level array’ is closed to new replies.