Siteurl filter for upgrades in multisite mode

[axelseaa]

We have an WPMU setup, and are moving it behind a load balancer which causes the site upgrade scripts to fail when php trys to load the sites. I've found that by adding a filter on siteurl and massaging the url to bypass our load balancer the upgrade scripts then run correctly.

Attached is a patch which adds a filter option to the siteurl query in ms-upgrade-site.php

Is this something that can be added?

[nacin]

We should probably convert that query to get_blog_option(), then you can use the filters already there.

[axelseaa]

If it was converted to get_blog_option - how would I only have a filter apply to the upgrade page and not other calls? Everything else works fine - the only time I need to hook into modify it is when performing the upgrade.

[nacin]

Replying to axelseaa:

If it was converted to get_blog_option - how would I only have a filter apply to the upgrade page and not other calls? Everything else works fine - the only time I need to hook into modify it is when performing the upgrade.

-1 on a dedicated filter. It needs to be converted to use the API anyway. When that happens, multiple hooks become available that can filter the option value. (You limit something to a page by checking what page you're on.) Additionally, you can easily filter via wp_remote_get() as it stands now.

[dd32]

We have an WPMU setup, and are moving it behind a load balancer which causes the site upgrade scripts to fail when php trys to load the sites.

You'll find you'll have cron issues as well (Cron is used by tasks such as pings, trackbacks, update checking, and most importantly, future publishing posts).

The general "fix" for this is for the server to be changed to resolve the domain name in question to itself(via /etc/hosts or similar), rather than to the load balancer - But i'm not sure how that'll play with WPMU.

[wpmuguru]

Replying to dd32:

The general "fix" for this is for the server to be changed to resolve the domain name in question to itself(via /etc/hosts or similar), rather than to the load balancer - But i'm not sure how that'll play with WPMU.

That should work for MU as well. Locally I use my hosts file to work with local MU installs and upgrades, etc, work fine.

get_blog_option calls switch_to_blog which is a fairly expensive call. As mentioned, there are filters on the wp_remote_get that can be used. You can add filters there and check the remote IP to see if the request is coming from MU.

Another alternative is to upgrade using a client that cycles through the list requesting each blog in turn.

[nacin]

So since get_blog_option is expensive and I guess unnecessary, and there's already a filter for wp_remote_get(), I'm thinking worksforme?

Should we consider an API that does blog option lookups without switch_to_blog?

[nacin]

Wait, it doesn't use switch_to_blog:

 256          $blog_prefix = $wpdb->get_blog_prefix( $blog_id );
 257          $row = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM {$blog_prefix}options WHERE option_name = %s", $setting ) );

Sounds like switching to the API could actually be quicker as it includes caching.

[nacin]

add_, update_, and delete_ use switch_to_blog().

Patch attached utilizes the API. I've also updated get_blog_option to use untrailingslashit().

[wpmuguru]

Replying to wpmuguru:

get_blog_option calls switch_to_blog which is a fairly expensive call.

correction - that _blog_option function doesn't call switch_to_blog. The other ones do.

[wpmuguru]

(In [12952]) add siteurl filter for ms upgrades, props nacin, fixes #12069