WordPress MU

On the off chance you're not following MU Trac, take a quick look at #980.

get_blog_option() is used to get an option from the specified blog but there's a trade off:
1. If we do it properly it's fairly slow. How slow? Read the ticket.
2. MU 2.7.1 used a hack to access the db directly but you lose the *_option filter which is quite important.

MU 2.7.1 out of the box doesn't use get_blog_option() that much, mostly for admin stuff, and registering new blogs. In MU trunk the function uses the slow but correct way. I've checked in changes to reduce the number of times it's called. Usually by switching to the new blog, calling get_option() multiple times and reverting back to the current blog. That improves things considerably.

So, do you use get_blog_option() in your plugin/theme? I'm tempted to use the slow method because it's more correct. I also plan on plastering the code with a big fat warning that the function is slow.

Speak up now or forever hold your tongue (or at least until the next major release.)

I've found it in 16 BuddyPress files in our installs and in Brian Samson's Multi-user plugin manager too (http://samson.blog.asu.edu/plugman (which we don't actually use anyway). So, it looks like BP's usage would be a primary concern, if it ties into the your version of the function.

Hi Donncha,

I'll scan my plugins and themes tonight. I've used used it before, but I don't remember where.

So, the next question would be why is switch_to_blog sooo slow.

There's a very minor optimization to be done at the top by switching the order of these statements:
if ( empty($switched_stack) )
$switched_stack = array();

$switched_stack[] = $blog_id;

if ( $blog_id == $new_blog )
return false;

So that the memory isn't initialized for the array if we aren't going to do anything, but that would be very minor.

The big time consumer looks like it would be the loading of the roles and capabilities. And really, that's not needed for a simple option lookup. I shudder at the possibility of this being abused, but is it possible to have a _temp_blog_switch() (& restore) that is used for non-security related tasks like retrieving an options value? How incredibly horrible would that be? It certainly would make things faster.

Brian - I thought about that too. It'd probably be perfectly ok for 99% of uses but what if an _option filter modified the filter based on the unchanged (user/role) data?

The switching stack array is filled in for the corresponding call to restore_current_blog() to pop off the blog_id.

Probably being paranoid but it's better to think of all the possibilities!

oh.. interesting. So some plugin's filter might return a different value (or more likely block a value) based upon what the current role is? ewwww... I'd say that then the person who did that deserves what they get, but it also sounds like some odd ball thing I'd end up having to do just to get something to work....

Well... you could then add a get_blog_option_ex() that does the full call. But wait a moment... Not only did this diff make the change to doing the full switch, but it also removed the object cache usage. No wonder it is slower... There's nothing in his ticket that says he HAS to constantly have the live value. Or am I missing an implied requirement. If you make this call the slow way, allowing his filters to work and alter the value, and then cache the result with the site in the key, for the subsequent calls, doesn't that resolve both issues?

The object cache is still there. The switching code has to initialise it to avoid poisoning the cache but if you're using a proper backend like Memcached that won't clear out the old values.

Buddypress does use get_blog_option() a lot, so if I can't come up with a simpler switching function for get_blog_option() and because:

1. Nobody complained that their *_option filter was broken and it's been like that for quite a while.
2. It was fairly fast before.

I may go back to the original fast code with the broken *_option filter.

I use it in an (is_site_admin) area for displaying an 'all blogs' table of specific wordpress options to augment the list of my proprietary options. get_blog_option() is generally used to insert things like admin_email, theme, etc.

For this purpose I don't really care that it's slow, since it's used on the back-end only to ease the process of viewing aggregate data like Monthly Post/Comment totals. It'd be inconvenient if it 'went away' unless there's a better option. The switch_to_blog() option doesn't seem like a good alternative.

This is definitely a difficult problem to solve.

As an experiment, I commented out the code in switch_to_blog() that relates to initialising the roles and capabilities, and the function is 4x faster.

I re-ran my benchmark and it took 4 seconds instead of 6.

Brian - I thought about that too. It'd probably be perfectly ok for 99% of uses but what if an _option filter modified the filter based on the unchanged (user/role) data?

I do agree that this could cause problems though.

What about going back to the old get_blog_option() way of doing things (from r1803), but also including the $blog_id variable in the apply_filters line?

That way if a plugin is required to know what blog id the option is fore, they can use the extra parameter to find out, and existing plugins can remain unchanged (they will just ignore the second parameter on the filter).

Is there a reason why BP couldn't be tweaked so that it didn't use get_blog_option?

The update_option_option_name could be used to store the info that BP needed.

After reading the posts here, talking with Andy Peatling on how BuddyPress uses get_blog_option and after sleeping on it, it's probably better go back to the old way it worked.

Anyone using get_blog_option() is a WordPress MU user, and will be/have to become aware of the lack of the *_option filter. I'll add a second parameter to the filter to specify the blog_id. I'll also add a warning in the code that the WP _option filter won't work.

I've just checked in the changes to get_blog_option(). Thoughts?

http://trac.mu.wordpress.org/changeset/1814