[buddypress-trac] [BuddyPress] #3261: BP options get/update wrapper functions

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Mon Jun 6 20:14:41 UTC 2011


#3261: BP options get/update wrapper functions
---------------------------+-----------------
  Reporter:  boonebgorges  |      Owner:
      Type:  defect        |     Status:  new
  Priority:  normal        |  Milestone:  1.3
 Component:  Core          |    Version:
Resolution:                |   Keywords:
---------------------------+-----------------

Comment (by boonebgorges):

 I'd like our approach to be consistent with different kinds of
 metadata/options. So if we are going to use a wrapper function for
 user_meta keys (which we are currently doing in the trunk with
 bp_get_user_meta_key()), then we should use a similar strategy for
 options, eg
 {{{
 update_site_option( bp_get_site_option_key( 'bp-active-components' ),
 $active_components );
 }}}

 The problem with this kind of approach is that it would (probably) require
 prefixing the key with the site id, eg bp_3-active-components or something
 like that. And this would mean that we were storing a bunch of clearly
 site-specific content in sitemeta. That seems wrong - that's the purpose
 of update_option(). Yet moving to update_option() means that we have to
 figure out something for backpat.

 If the conceptual mismatch of storing blog-specific meta in sitemeta using
 update_site_option() doesn't bother anyone, then we can just go along with
 this solution. (Ron can then filter this in the same way he does
 bp_get_user_meta_key() for multinetwork, and we can filter it internally
 when BP_ENABLE_MULTIBLOG is set.) This is something that can be done
 quickly and with full backpat. Thoughts/objections?

-- 
Ticket URL: <https://trac.buddypress.org/ticket/3261#comment:8>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list