Make WordPress Core

Opened 10 years ago

Closed 9 years ago

#14553 closed defect (bug) (fixed)

Prevent localized MS sites from stomping core update checks

Reported by: nacin Owned by:
Milestone: 3.1 Priority: normal
Severity: normal Version: 3.0
Component: Upgrade/Install Keywords: has-patch
Focuses: multisite Cc:


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.

Attachments (2)

14553.diff (1.4 KB) - added by nacin 10 years ago.
Adding an arg to get_locale()
14553.2.diff (1.4 KB) - added by nacin 10 years ago.
Addresses faulty logic.

Download all attachments as: .zip

Change History (15)

10 years ago

Adding an arg to get_locale()

#1 @nacin
10 years ago

  • Keywords has-patch added

#2 @nkuttler
10 years ago

  • Cc office@… added

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.

#3 @gazouteast
10 years ago

  • Cc gazouteast added

@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).


#4 @nkuttler
10 years ago

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 (?)

#5 @nkuttler
10 years ago

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.

10 years ago

Addresses faulty logic.

#6 follow-up: @nacin
10 years ago

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?

#7 @hakre
10 years ago

  • Keywords reporter-feedback added

#8 @gazouteast
10 years ago

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.

#9 @nacin
10 years ago

  • Milestone changed from 3.0.3 to 3.1

#10 @nacin
10 years ago

  • Milestone changed from 3.1 to Future Release

We now have

if ( ! is_main_site() )

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

#11 @SergeyBiryukov
9 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Future Release to 3.1

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.

#12 in reply to: ↑ 6 @nacin
9 years ago

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.

#13 @nacin
9 years ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.