Skip to:
Content

BuddyPress.org

Opened 13 years ago

Closed 13 years ago

#3380 closed defect (bug) (fixed)

Site options change not propagating properly in Multisite Install

Reported by: sbrajesh's profile sbrajesh Owned by:
Milestone: 1.5 Priority: normal
Severity: normal Version: 1.5
Component: Core Keywords: needs-patch 2nd-opinion
Cc: sbrajesh

Description

As of r4848 In a multisite install of WordPress, buddypress does not take into account the changes in site options.
For example, if we set the "registration" to none on a fresh mulsisite install and activate buddypress, buddypress will update the root blog with registration 'none' in its options table.

Now, even if we change the registration settings to 'all', it will not be considered by buddypress.
reason, buddypress initially looks into root blog and finds the registration option set to none, so it won't bother about any changes.

The problem lies in function 'bp_core_get_root_options()'

The easy way would be to handle the siteoptions which could change specifically like enabling/disabling registration can be handled specifically.

How to reproduce:=

Try changing your current registration setting on multisite(for example if it is set to all, set to none and check if buddypress takes that into account ?)

Change History (4)

#1 @boonebgorges
13 years ago

  • Keywords needs-patch 2nd-opinion added
  • Milestone changed from Awaiting Review to 1.3

Thanks for the detailed report, sbrajesh, and good call.

I think that the settings were arranged in this way so that we could avoid an additional query on each pageload (one to sitemeta, one to the local blog's options). So we have two options to fix this. (1) Split it back into to separate queries, or (2) Have a listener on the MS-specific options that will sync the blog options whenever our MS options are changed.

I guess I lean toward the latter. Anyone else have any thoughts?

#2 @sbrajesh
13 years ago

Hi Boone,
Thank you for the confirmation.
A little more testing shows when BP_ENABLE_MULTIBLOG is set the options are copied to individual blogs options table. So, if we go through the second approach, we may have to update it for each of the blog. It may be a little bit too much to keep the options consistent in that case, what do you think ?

One more thought, how about keeping the options in two group (one for current site and one for sitewide?). That may be just two queries, but I am not sure if that will be a good way. Looking to your and other core dev's opinion.

#3 @boonebgorges
13 years ago

Good point about BP_ENABLE_MULTIBLOG. That's a pain.

For that reason, I think that you're right that we'll need to do this in two queries. I don't see another way around it.

#4 @boonebgorges
13 years ago

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

(In [4855]) Ensure that sitewide options always come from sitemeta in bp_core_get_root_options(). Fixes #3380

Note: See TracTickets for help on using tickets.