Prevent localized MS sites from stomping core update checks

[nacin]

For reasons currently passing my understanding, we fire core, plugin, and theme checks on all sites in a network.

One issue is if sites run different locales, then they will stomp on the transient set by the previous check and potentially return bad information.

Example. The network runs 3.0.1. WPLANG is set to '', which means get_locale() would return en_US. When site A runs an update check, there's no update. Site B has a blog-level WPLANG option of de_DE. When it runs an update check, the API returns 3.0.1-de_DE, even though the install is defined as 3.0.1-en_US. As this is then stored in a sitemeta transient, each update stomps over the last, and so depending on whether an en_US blog or de_DE blog ran the update check last, you may have a very annoying nag telling you to upgrade to the version you're already at.

Ironically, this is a performance improvement over MU (even if more annoying), since MU stored update check results in a blog transient. Instead of the checks stomping each other, they all ran independently.

I'm not sure of the fix here. I'm not convinced we should put logic in either get_locale() or wp_version_check(). Nor do I think we should attach a MS default filter.

Here's my idea currently -- introduce get_network_locale(), or a $network_wide = false argument on get_locale(), that would skip checking the blog-level WPLANG option.

Originally reported by nkuttler in IRC yesterday.

I'll be opening a new ticket on 3.1 to restrict core, plugin, and theme update checks to the root site only. Thankfully, our network admin makes that a bit more intuitive.

[nacin]

Adding an arg to get_locale()

[nkuttler]

I tested the patch and it fixes the nag messages for me, for all blogs and after deleting the _site_transient_update_core entry repeatedly.

[gazouteast]

@nkuttler - could you elaborate please on "after deleting the _site_transient_update_core entry repeatedly" - I have one very problematic standalone site that this may assist (it keeps getting thumped for server resource abuse despite the site being almost a ghost town nowadays).

thanks

[nkuttler]

Apply the patch and run this in your db:

delete from wp_sitemeta where meta_key='_site_transient_update_core';

I kind of doubt this bug can cause any performance issues though (?)

[nkuttler]

Oh, I just noticed a bug with this patch. The blog completely it's WPLANG setting as defined on the blog settings page (backend and frontend weren't localized any more). I'll have a look as soon as I can.

[nacin]

Addresses faulty logic.

[nacin]

New patch. I also noticed that we should probably be pulling get_site_option('WPLANG') even if WP_INSTALLING is defined, such as when activating a new blog... So that might be another bug?

[gazouteast]

thanks nkuttler - I'm waiting until nacin finishes his checks from his last post then will try this on the problematic install to see if it helps.

[nacin]

We now have

if ( ! is_main_site() )
	return;

in wp-includes/update.php. Not sure if there's anything else here need solving.

[SergeyBiryukov]

Since [15591], update checks are only run from the main site, so this is fixed.

I was thinking if we should only show the update nag on the main site, but leaving it as is also makes sense.

[nacin]

Replying to nacin:

New patch. I also noticed that we should probably be pulling get_site_option('WPLANG') even if WP_INSTALLING is defined, such as when activating a new blog... So that might be another bug?

Follow up: #18783.