Add *_user_meta() functions

[scribu]

Since we have a new generic meta API, we should use it on user metadata too.

Also, the old *_usermeta() functions should be deprecated at some point.

[scribu]

Related: #7540, #10327

[scribu]

Also related: #9065

[ryan]

Good for early 3.0.

[ryan]

Can we switch some places in core to use this so we're eating our own dogfood when this goes in?

[ramiy]

scribu, change the phpDoc to v3.0.

[hakre]

Replying to ramiy:

scribu, change the phpDoc to v3.0.

comitter can do when commit is done.

[arena]

Hi all,

just to let you know,

current code to access usermeta data has the metakey value changed by the following code :

$meta_key = preg_replace('|[^a-z0-9_]|i', '', $meta_key);

so meta_key such as 'manage-edit-comments-columns-hidden'

is stored as 'manageeditcommentscolumnshidden'

• i believe this is why usermeta has not been changes in 2.9 .

• patch should still change metakey value for compatibility with existing datas.

[arena]

oh ! and missed this one :

WP Mu has only one usermeta table and a postmeta table per blog ...

so 3.0 still merging WP and WPµ ?

[scribu]

Replying to arena:

• patch should still change metakey value for compatibility with existing datas.

No, it shouldn't. That's why we're adding a new set of functions: so that we don't have to worry about compatibility and be consistent with *_post_meta() functions.

[scribu]

Replying to arena:

oh ! and missed this one :

WP Mu has only one usermeta table and a postmeta table per blog ...

so 3.0 still merging WP and WPµ ?

I guess we should wait until after most of the merging with MU is done.

[technosailor]

The patch should still be good. The *_user_meta() functions just wrap around the relative *_metadata() functions. Compat with MS installs should be handled transparently downstream and should not block inclusion of this patch here.

[nacin]

There's only about 60 references to the functions these would cause to be deprecated, so we can probably make the switch pretty easily.

Just a note, there is currently no add_usermeta() function, just update_usermeta().

[technosailor]

Updates patch to 3.0. Also deprecates old *_usermeta functions in exchange for new *_user_meta() functions that use new metadata API.

[technosailor]

Replying to nacin:

There's only about 60 references to the functions these would cause to be deprecated, so we can probably make the switch pretty easily.

There's really no reason to update those 60 refs right now if using my patch. The old functions are deprecated and turned into wrappers around the new functions for BC reasons.

[nacin]

(In [13300]) Introduce *_user_meta() functions, deprecate *_usermeta() family. Fixes #10837 props scribu, technosailor.

[technosailor]

Eats our own dog food patch

[nacin]

(In [13311]) Don't use deprecated *_usermeta() functions. Props technosailor fixes #10837

[TobiasBg]

I haven't checked or tested this, nor do I need if we should take action, but from this BP Trac report, it sounds as if [13300] could potentially break backward compatibility:
​http://trac.buddypress.org/ticket/2048

[nacin]

The old *_usermeta() functions should be backwards compatible.

I'm working on a patch right now to restore the same hooks and return values. If necessary we can return the original function definitions for *_usermeta(). Getting some second eyes on this could help.

[nacin]

(In [13326]) Ensure we're back compat with return values and actions in deprecated *_usermeta() family. See #10837

[nacin]

(In [13329]) Switch over to *_user_meta() syntax. The old get_usermeta() would return a string when only one value was found, get_user_meta() requires $single = true. Fixes #10837