Make WordPress Core

Opened 5 years ago

Closed 4 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 5 years ago.
Adding an arg to get_locale()
14553.2.diff (1.4 KB) - added by nacin 5 years ago.
Addresses faulty logic.

Download all attachments as: .zip

Change History (15)

@nacin5 years ago

Adding an arg to get_locale()

comment:1 @nacin5 years ago

  • Keywords has-patch added

comment:2 @nkuttler5 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.

comment:3 @gazouteast5 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).


comment:4 @nkuttler5 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 (?)

comment:5 @nkuttler5 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.

@nacin5 years ago

Addresses faulty logic.

comment:6 follow-up: @nacin5 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?

comment:7 @hakre5 years ago

  • Keywords reporter-feedback added

comment:8 @gazouteast5 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.

comment:9 @nacin5 years ago

  • Milestone changed from 3.0.3 to 3.1

comment:10 @nacin5 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.

comment:11 @SergeyBiryukov4 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.

comment:12 in reply to: ↑ 6 @nacin4 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.

comment:13 @nacin4 years ago

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