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 | 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
@
13 years ago
- Keywords needs-patch 2nd-opinion added
- Milestone changed from Awaiting Review to 1.3
#2
@
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.
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?