Skip to:

Opened 12 years ago

Closed 12 years ago

#1823 closed defect (bug) (wontfix)

Some WordPress core functions need to be mappable

Reported by: johnjamesjacoby's profile johnjamesjacoby Owned by: johnjamesjacoby's profile johnjamesjacoby
Milestone: 2.1 Priority: normal
Severity: normal Version: 2.0
Component: Tools - Code Improvements Keywords:

Description (last modified by 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...

Attachments (3)

1823.patch (3.7 KB) - added by johnjamesjacoby 12 years ago.
1823.2.patch (885 bytes) - added by johnjamesjacoby 12 years ago.
1823.3.patch (13.5 KB) - added by johnjamesjacoby 12 years ago.
bbp_*_user_meta functions

Download all attachments as: .zip

Change History (7)

#1 @johnjamesjacoby
12 years ago

  • Description modified (diff)

12 years ago

bbp_*_user_meta functions

#2 @tott
12 years ago

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

#3 @nacin
12 years ago

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, 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'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.

#4 @johnjamesjacoby
12 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Thanks Andy for the consult.

Closing this as wontfix.

Related #1826.

Note: See TracTickets for help on using tickets.