WordPress.org

Make WordPress Core

Opened 20 months ago

Last modified 3 weeks ago

#42965 reopened defect (bug)

Widgets not restored to previous widget area after switching back to previous theme

Reported by: probewise Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9
Component: Widgets Keywords: needs-patch
Focuses: Cc:

Description

There's a bug in widgets when switching themes. Before, on version 4.8.4, if you switch themes and return it back to previous, widget will retain on its widget column. In the latest version 4.9.1, every time you switch themes and return it back to previous one, all widgets will automatically placed to Inactive widgets.

Change History (15)

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


20 months ago

#2 @westonruter
20 months ago

  • Keywords reporter-feedback added
  • Summary changed from Widget bug to Widgets not restored to previous widget area after switching back to previous theme
  • Version changed from 4.9.1 to 4.9

This was worked on in #39693.

@probewise I cannot reproduce the problem. I tried adding a widget to a sidebar in Twenty Fifteen, then I switched to Twenty Sixteen, an then back to Twenty Fifteen and the widget I added in Twenty Fifteen was restored to the previous sidebar.

Please share the themes you're specifically testing with, and the steps you're doing. Sharing a screencast would be particularly helpful.

#3 @probewise
20 months ago

Yes, it will be restored if it's only using the default widget column/area, meaning if you're only using the primary sidebar/widget area. But if you'll switch theme with additional widget area, take for example, switching Twenty Fourteen to Twenty Fifteen, Content Sidebar/Widget Area's widget will be reassign to the primary Sidebar of Twenty Fifteen (see screenshots, Calendar was moved to Primary Sidebar/Widget Area). Switching other themes with multiple widget column/area, it will be placed to Inactive Widgets, and other widgets will be reassigned to other widget column/area. See screencast here: https://youtu.be/-Oh8_j5UvWU

#4 follow-up: @westonruter
20 months ago

  • Keywords needs-patch added; reporter-feedback removed
  • Milestone changed from Awaiting Review to 4.9.2

@probewise thank you for that excellent screencast showcasing the problem. The soundtrack makes it all the more enjoyable 😀

So the problem is that if you have two widget areas A & B, with widgets A1 and B1 assigned respectively, then you switch to another theme with just a single widget area A, then it will get assigned both widgets A1 and B1. So far so good. But if you then switch back to the previous theme, then widget area A still has both A1 and B1, with widget area B being incorrectly empty.

@obenland I thought the algorithm for restoring widgets was first assigning widgets back to their previous locations before then trying to re-assign any newly-created widgets using best guessing?

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


19 months ago

#6 @joyously
19 months ago

This was what I mentioned while oberland was testing the new assignments. In order to get screenshots for a ticket, I went through the core themes in order (2010 to 2017) and then back again, and had to redo my widgets for each one.

#7 in reply to: ↑ 4 @obenland
19 months ago

Replying to westonruter:

I thought the algorithm for restoring widgets was first assigning widgets back to their previous locations before then trying to re-assign any newly-created widgets using best guessing?

No it doesn't, it maps first and then tries to revive. The idea behind that was that presumably widget assignments change more often than themes are being switched, and switching themes back and forth was mitigated by the Customizer.
Switching that would also change the order of widgets, with previously existing ones being added first and new ones appended.

#8 @dd32
19 months ago

  • Milestone changed from 4.9.2 to 4.9.3

Bumping to 4.9.3 due to 4.9.2s release

This ticket was mentioned in Slack in #core by desrosj. View the logs.


19 months ago

#10 @desrosj
19 months ago

  • Milestone changed from 4.9.3 to 4.9.4

Punting because this still needs a patch.

#11 @obenland
19 months ago

Personally I don’t think it does :)

#12 @dd32
19 months ago

  • Milestone changed from 4.9.4 to 4.9.5

Bumping, 4.9.4 has been released.

#13 follow-up: @SergeyBiryukov
18 months ago

  • Keywords close added

Per comment:7, the current behavior appears to be the expected one.

#14 @westonruter
18 months ago

  • Milestone 4.9.5 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#15 in reply to: ↑ 13 @joyously
3 weeks ago

  • Keywords close removed
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to SergeyBiryukov:

Per comment:7, the current behavior appears to be the expected one.

I don't read it that way at all. I think this is still broken.
What I expect to get when I switch themes is the widgets set the way I last left them. Obviously, the OP expects that also.

Replying to obenland:

The idea behind that was that presumably widget assignments change more often than themes are being switched, and switching themes back and forth was mitigated by the Customizer.

This presumption doesn't include these common cases

  • programmatic theme switching (front end switching, or admin for fatal errors)
  • those of us that do theme review (or just like switching themes)
  • troubleshooting by switching to a default theme (many support topics recommend)
  • widgets provided by the theme should remain, for that theme

The Customizer is not always used to switch themes. And widget assignments generally are tailored to the theme's widget areas anyway.

Note: See TracTickets for help on using tickets.