id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
14553	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."	defect (bug)	closed	normal	3.1	Upgrade/Install	3.0	normal	fixed	multisite has-patch	office@… gazouteast