WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 8 months ago

#19846 new defect (bug)

Specify 'primary' sidebar, so widgets land in correct sidebar when changing themes

Reported by: billerickson Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.3.1
Component: Widgets Keywords: needs-patch dev-feedback
Focuses: Cc:

Description

With the improvements to widget handling in 3.3, the widgets in a previous theme's sidebar are transferred to your current theme's sidebar. But there's no way to specify which sidebar should receive them.

For example, when you activate the Genesis theme it has three widget areas:

  • Header Right
  • Primary Sidebar
  • Secondary Sidebar

If you install a fresh copy of WP and then activate Genesis, the Header Right widget area is populated with the 6 default widgets ( http://twitpic.com/8618x5 ). It's definitely not ideal for new users unfamiliar with this.

It would be great if there were some way to specify a primary sidebar when registering it, and that's the one the default widgets flow into.

register_sidebar( array( 'name' => 'Primary Sidebar', 'id' => 'primary-sidebar', 'primary' => true );
register_sidebar( array( 'name' => 'Secondary Sidebar', 'id' => 'secondary-sidebar' );
// Default: 'primary' => false

There might be better ways to handle this, but I think it should be done in WP core. If it's up to the themes to solve, we'll have to use solutions like this: https://gist.github.com/1623202

Change History (9)

comment:1 nathanrice2 years ago

  • Cc ncrice@… added
  • Keywords needs-patch added

+1 to this.

I think the problem may go deeper than just moving from sidebar to sidebar. If I'm not mistaken, WordPress seeks to transfer ALL your active widgets to a new destination when switching themes.

It's naive to assume that widget areas are always sidebars, and are therefore equipped to style the transferred widgets properly.

But as Bill points out, this is specifically a problem with Twenty Eleven. Because Twenty Eleven front-loads widgets into the sidebar (instead of letting them be empty by default), a fresh install of WordPress followed by a fresh install and activation of another theme, can very likely end up with misplaced widgets.

Sorry we didn't catch this earlier. We obviously would have reported it before 3.3 was released, if we had known.

comment:2 nacin2 years ago

Twenty Eleven doesn't do the frontloading. WordPress does, and has since 3.0. See #12163.

It's naive to assume that widget areas are always sidebars, and are therefore equipped to style the transferred widgets properly.

That's the actual issue here, I'd think.

It would probably be best if Genesis registered its sidebars in order of descending precedence, or at least made the first one "primary".

comment:3 nathanrice2 years ago

From a UX perspective, registering the widget areas in the order they display on the page is much better than registering them in order of precedence.

comment:4 travisnorthcutt2 years ago

  • Cc travis@… added
  • Summary changed from Specify 'primary' sidebar, so widgets land in right sidebar when changing themes to Specify 'primary' sidebar, so widgets land in correct sidebar when changing themes

+1 to what nathanrice said. I had a longer reply typed up, but his is more clear :).

(Bill, I changed your title slightly to be a little more clear - hope that's ok)

comment:5 DrewAPicture2 years ago

  • Cc xoodrew@… added

comment:6 sabreuse2 years ago

  • Cc sabreuse@… added

comment:7 jaredatch2 years ago

  • Cc jared@… added

comment:8 nathanrice22 months ago

I really have to insist that this be given another look for the next dev cycle. I know the idea is to create a better user experience when switching themes (#19300), and a comprehensive solution is preferable, I don't think the current solution is sufficient in the mean time.

Personally, I think that moving widgets to inactive when the widget areas don't have analogs in the new theme (same ID) is a perfectly fine solution. But if that's unacceptable, or considered regression, I can get on board with Bill's idea to specify a widget area to dump widgets in when switching themes. I'd be willing to write up a patch, if I knew it'd be worth it to do so.

Other ideas have been floated, including the idea of widget groups being assigned to widget locations (much like menus), as well as some mention of using the theme customizer to manage the transition of widgets from one theme to another, which evidently never materialized.

Now that 3.4 is out, I'd like to push to make this a priority in 3.5, if at all possible. The current implementation is just too roughshod.

comment:9 c3mdigital8 months ago

  • Keywords dev-feedback added
Note: See TracTickets for help on using tickets.