[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