Make WordPress Core

Opened 11 years ago

Closed 11 years ago

#27347 closed defect (bug) (invalid)

Widget Customizer: Only Widgets of Child Theme Editable, Parent Theme Widgets Missing

Reported by: daveshine's profile daveshine Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9
Component: Widgets Keywords:
Focuses: Cc:

Description

The Widget Customizer does not recognize the Widgets from the parent theme. I've tested with child themes of "Stargazer" (via WordPress.org repo) as well as child themes of Genesis Framework.

This is very confusing as in the Widgets Admin you may have 7 Widget Areas but in Customizer maybe only 4 of them.

ALL widget areas should be populated as in Widgets admin already. Widget Customizer should not be dependent of theme/ child theme but dependent of the registered areas, obviously.

Tested with 3.9-alpha-27445 and in latest Firefox and Chrome (Beta) browsers.

I am not sure if #27177 is related here (but that was reported as Widget Customizer wasn't in core then...).

Change History (6)

#1 follow-ups: @nacin
11 years ago

  • Milestone changed from Awaiting Review to 3.9

I'm pretty sure it only displays sidebars that appear on the page you're on. It's a cool idea in theory, but it can be confusing (and some widget areas are pretty buried due to context, forcing someone to click around in the preview window so they can edit it). It might be worth showing these not-being-previewed widget areas but with some kind of indication they're not shown on that particular page.

#2 in reply to: ↑ 1 @daveshine
11 years ago

Replying to nacin:

I'm pretty sure it only displays sidebars that appear on the page you're on.

Yes, you're right on this! I'm sorry but was totally not aware of it before...!

It's a cool idea in theory, but it can be confusing (and some widget areas are pretty buried due to context, forcing someone to click around in the preview window so they can edit it).

Right, it confused me from UI point of view a bit so I thought it was a bug. Now you've explained it's now clear to me.

Maybe other users will have same experience as I had, so I suggest to make any (tiny) notice or whatever to make it more clear what areas are previewed or that the customizer view/preview in general only effects the page currently in view.

It might be worth showing these not-being-previewed widget areas but with some kind of indication they're not shown on that particular page.

+1
Would be awesome!

#3 in reply to: ↑ 1 ; follow-up: @westonruter
11 years ago

Replying to nacin:

I'm pretty sure it only displays sidebars that appear on the page you're on. It's a cool idea in theory, but it can be confusing (and some widget areas are pretty buried due to context, forcing someone to click around in the preview window so they can edit it). It might be worth showing these not-being-previewed widget areas but with some kind of indication they're not shown on that particular page.

Correct. Customizer sections for widget areas only appear on previewed URLs that contain that widget area (sidebar) used in the template (i.e. dynamic_sidebar() is used). By hiding the sections for widget areas not shown in the preview, we can conserve a lot of space in the customizer. If all widget area sections are always shown, the sidebar would be very cluttered.

One solution would be to include some messaging to direct users that they should navigate to the page that has the sidebar in use and then enter the customizer from there. They can either navigate to this page from within the customizer or from the frontend and click the link in the admin bar.

Alternatively, or complementarily, all the widget area sections should be grouped into one meta section, as shaunandrews has proposed. With this in place, there could be a checkbox/button to toggle between showing only the widget areas currently used in the previewed URL, or to show all of the widget areas regardless but with some additional indicator (such as being faded out).

Originally discussed at https://github.com/x-team/wp-widget-customizer/issues/77

@nacin: Shall I create a new Trac ticket for this with the expectation it would be part of a post-3.9 milestone?

#5 in reply to: ↑ 3 @westonruter
11 years ago

Replying to westonruter:

@nacin: Shall I create a new Trac ticket for this with the expectation it would be part of a post-3.9 milestone?

Opened #27406

#6 @westonruter
11 years ago

  • Milestone 3.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed

The issues raised in this ticket will be resolved in #27406

Note: See TracTickets for help on using tickets.