Some WordPress core functions need to be mappable

[johnjamesjacoby]

Some WordPress core functions need to be mappable, to allow their respective data to exist in other non-conventional database tables:

• get/add/update/delete/_user_meta
• get/add/update/delete/_post_meta
• get/add/update/delete/_option
• get/add/update/delete/_site_meta

This is to allow huge installations to map to custom tables, where needed. An example is storing certain user_meta in a separate table that won't cause user cache invalidation. Something similar could be done for post_meta, blogs, etc...

[johnjamesjacoby]

bbp_*_user_meta functions

[tott]

bbp_add_user_meta, bbp_delete_user_meta still lack the meta_key in the filter functions. will sent patch after testing

[nacin]

A few thoughts:

The core metadata API already has the ability to short-circuit all four CRUD methods using very simple filters. For a highly unusual setup like WP.com, I would think it would make far more sense to leverage those filters. The alternative — this patch — adds a burden to developers by making it more difficult to maintain (one errant use of the core method and suddenly you have a problem). It also confuses plugin authors.

   $check = apply_filters( "update_{$meta_type}_metadata", null, $object_id, $meta_key, $meta_value, $prev_value );
    if ( null !== $check )
        return (bool) $check;

    $check = apply_filters( "add_{$meta_type}_metadata", null, $object_id, $meta_key, $meta_value, $unique );
    if ( null !== $check )
        return $check;

    $check = apply_filters( "delete_{$meta_type}_metadata", null, $object_id, $meta_key, $meta_value, $delete_all );
    if ( null !== $check )
        return (bool) $check;

    $check = apply_filters( "get_{$meta_type}_metadata", null, $object_id, $meta_key, $single );
    if ( null !== $check ) {

So even with this patch, you'd have to hook into four new filters and then call other functions, possibly requiring a wrapper in order to call existing functions in a library such as WP.com's user attributes. Or, you can use the four existing filters, look for keys that start with _bbp_ or {$wpdb->prefix}_bbp_, and then use your alternative storage mechanism. So it's a wash for the unusual setup; meanwhile, the pro/cons are pretty strongly tilted.

Sidenote, the use of user_option over user_meta is a bit weird here. Nearly all of these user metas should actually be user options, no? Should _bbp_topic_count really be global? I suppose in some cases (global profiles), sure; in other cases, it doesn't make much sense. I don't necessarily see the need to do s/_user_meta/_user_option/g on the codebase (and that could break quite a bit for existing sites). However, I would definitely convert all get_user_meta() calls to get_user_option(). In fact, core does this in a few places — saves something globally, but then uses get_user_option() to allow a plugin to use it per site. (Also, for the current user, only one argument is needed.)

Sidenote 2, $function() does not allow for class or object methods to be called. You'd want to use call_user_func() or call_user_func_array().

I'm not arguing against wrappers. I'm only arguing against wrappers for this use case. BuddyPress very effectively uses wrappers to allow for a plugin to actually alter the key — designed specifically so a plugin can choose among site-wide, network-wide, and global meta key implementations. But that is a major design decision, one that should not be forced or rushed with a less-than-valid use case.

[johnjamesjacoby]

Thanks Andy for the consult.

Closing this as wontfix.

Related #1826.