WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 8 months ago

#19846 closed defect (bug) (duplicate)

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

Reported by: billerickson Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: Widgets Keywords: dev-feedback has-patch
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

Attachments (1)

19846.diff (4.2 KB) - added by welcher 2 years ago.

Download all attachments as: .zip

Change History (14)

#1 @nathanrice
6 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.

#2 @nacin
6 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".

#3 @nathanrice
6 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.

#4 @travisnorthcutt
6 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)

#5 @DrewAPicture
6 years ago

  • Cc xoodrew@… added

#6 @sabreuse
6 years ago

  • Cc sabreuse@… added

#7 @jaredatch
6 years ago

  • Cc jared@… added

#8 @nathanrice
6 years 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.

#9 @c3mdigital
4 years ago

  • Keywords dev-feedback added

#10 @chriscct7
2 years ago

  • Version changed from 3.3.1 to 3.3

#11 @billerickson
2 years ago

For reference, this is how Genesis currently handles the issue: https://gist.github.com/billerickson/0c54ab30cb6eaff84b55

#12 @welcher
2 years ago

  • Keywords has-patch added; needs-patch removed

I've added a patch that does the following:

  1. Adds an is_primary argument to register_sidebar() with a default of false
  2. Adds a new function called wp_get_primary_widget_areas that loops $wp_registered_sidebars and returns an array of all areas marked as 'is_primary - this is a bit naive at the moment as it only adds them as they are found in the array but the framework is there to do more moving forward.
  3. Adds a check in switch_theme() to see if the current them has a primary area and uses set_transient() to store it temporarily
  4. Added logic in retrieve_widgets() to look for a primary widget area in the new theme and assign content to it.

Would love any feedback.

@welcher
2 years ago

#13 @westonruter
8 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

This is being addressed in #39693.

Note: See TracTickets for help on using tickets.