Make WordPress Core

#49831 closed defect (bug) (fixed)

Multisite: themes should not be allowed to be updated from the Appearance > Themes screen of a subsite

Reported by: pbiron Owned by: johnbillion
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: has-screenshots has-patch commit
Focuses: multisite Cc:


In a multisite installation, plugin updates are are not displayed on subsite Plugins screen...and to update a plugin you must be on the Network Admin > Plugins screen.

However, themes can be updated from the subsite Themes screen (see screenshot). What is really odd, is that in the Theme Details modal on subsites, the fact that an update is available is shown, but you can't actually update :-)

Attachments (4)

theme-update-in-subsite.png (233.8 KB) - added by pbiron 20 months ago.
theme-details-modal-in-subsite.png (55.4 KB) - added by pbiron 20 months ago.
49831.diff (1.8 KB) - added by afragen 15 months ago.
49831.1.diff (1.1 KB) - added by pbiron 15 months ago.

Download all attachments as: .zip

Change History (17)

#1 @pbiron
20 months ago

  • Keywords has-screenshots added

This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.

15 months ago

#3 @pbiron
15 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.6
  • Owner set to pbiron
  • Status changed from new to assigned

15 months ago

#4 @afragen
15 months ago

  • Keywords has-patch needs-testing added; needs-patch removed

49831.diff seems to work but needs testing.

Last edited 15 months ago by afragen (previous) (diff)

15 months ago

#5 @pbiron
15 months ago

49831.1.diff takes a different approach than 49831.diff.

Instead of just hiding the update link, it doesn't even show the "Update Available" banner. It also results in updates not showing as being available in the Customizer.

I think this approach brings the Themes screen into parity with the Plugins screen, where the fact that updates are available is also not displayed.

This patch also needs testing :-)

#6 @afragen
15 months ago

Preliminary testing shows both patches function as they are designed.

I think bringing parity with plugins is probably a better idea.

This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.

14 months ago

#8 @afragen
14 months ago

  • Keywords commit added

#9 @pbiron
14 months ago

  • Keywords needs-testing removed

#10 @johnbillion
14 months ago

  • Owner changed from pbiron to johnbillion
  • Status changed from assigned to reviewing

#11 @johnbillion
14 months ago

I'm surprised this hasn't been picked up before. Makes me wonder if it's a regression.

Agreed that 49831.1.diff is the preferred approach (preventing $updates from being populated at all) and brings the Themes screen behaviour inline with that of the Plugins screen.

This change doesn't affect the Network Admin -> Themes screen which uses the list table instead of the grid view.

#12 @helen
14 months ago

I wanted to see if there was a preponderance of plugin developers using wp_prepare_themes_for_js() in a way that uses that update data and there doesn't appear to be. I think there is a small chance that somebody somewhere has a custom network admin screen that relies on this data, but the data can be filtered back in if they need it. Hopefully we don't trip over ourselves in the future should we need this data in the network admin :) Committing.

#13 @helen
14 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 49253:

Upgrade/Install: Don't show theme update prompts on subsites.

If you are using wp_prepare_themes_for_js() and relying on updates/no_updates in multisite, you will need to filter that data back in using the wp_prepare_themes_for_js hook.

Props pbiron, afragen.
Fixes #49831.

Note: See TracTickets for help on using tickets.