Opened 13 years ago
Closed 7 years 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)
Change History (14)
#2
@
13 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
@
13 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
@
13 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)
#8
@
12 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.
#11
@
9 years ago
For reference, this is how Genesis currently handles the issue: https://gist.github.com/billerickson/0c54ab30cb6eaff84b55
#12
@
9 years ago
- Keywords has-patch added; needs-patch removed
I've added a patch that does the following:
- Adds an
is_primary
argument toregister_sidebar()
with a default offalse
- 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. - Adds a check in
switch_theme()
to see if the current them has a primary area and usesset_transient()
to store it temporarily - 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.
+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.