Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 19 months ago

#33052 closed defect (bug) (fixed)

Widgets section in customize late to show up

Reported by: kidsguide's profile kidsguide Owned by: westonruter's profile westonruter
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.9
Component: Customize Keywords: has-patch needs-testing
Focuses: javascript Cc:


Widgets section is showing up late on the customizer.
Tested on Internet Explorer and Firefox

Change History (28)

#1 @westonruter
9 years ago

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

This is intentional. When the Customizer first loads, it doesn't know which widget areas (sidebars) are utilized (if any) in the template for the URL being previewed. So it has to wait for the Preview to load in order to know whether widgets are available to be Customized, and thus whether the Widgets panel should be displayed.

#2 @kidsguide
9 years ago

Ok, thanks. Didn't know if this was a bug or intentional.

#3 @westonruter
9 years ago

  • Focuses javascript added
  • Keywords needs-patch added
  • Milestone set to 4.4
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 4.3 to 3.9

Re-opening due to good argument raised by @pavelevap on #33687. In response, I commented:

It's not necessarily that the theme does not register any widget areas. In this case, the widgets panel should be hidden from the start (I'd have to double check that). The issue is when there are no dynamic_sidebar() calls in the current preview.

But I think you have a point: if no sidebars are rendered in the preview, there will not be any sidebar sections shown in the widgets panel. In this case, the panel is empty. What we could do in this situation is show some message in the panel when there are no active sidebar sections to explain why nothing is there, and to instruct users that they should navigate around the site within the preview to access the template that has the sidebar they want to modify.

#4 @westonruter
9 years ago

This may be a dependency for #32667, i.e. it will facilitate having the widgets panel open when autofocusing.

#5 @westonruter
9 years ago

I also consider this change to be a dependency for lazy-loading widget settings (#28580), since the initial expanding of the widgets panel would be trigger for lazy-loading the settings and controls. (We'd also need to lazy-load widgets when the widgets panel, a widget area section, or a widget control is autofocused.) See also #32667.

#6 @westonruter
9 years ago

  • Keywords has-patch needs-testing needs-unit-tests added; needs-patch removed

See 33052.diff.

Video demo:

Widgets panel will now show initially even if no widget areas are rendered in the preview. It will be hidden and remain hidden if no sidebars are registered.

If opening the widgets panel and there are no sidebars currently rendered in the preview, then a notice is displayed with instructions for how to access the desired sidebar for management (via navigating in the preview window).

If a widget area section is expanded, then when navigating in the preview to a URL that does not have a dynamic_sidebar() call, then the widget area section will be collapsed and the user will be bumped up to the widgets panel instead of the root of the Customizer.

This patch also fixes autofocusing on panels that are inactive, making focus (and expand) a no-op if the element (or its container) is not active. This fixes a bug where the Customizer panel can empty itself without a way for the user to go back. That bug can be demonstrated by running the following in the JS console:

wp.customize.section('colors').deactivate({ completeCallback: function(){ 

This PR also fixes an issue where an additional pane-contents-reflowed event handler to each time a section or panel would be expanded. It also fixes an incorrect top-margin that would result when a panel's sections would toggle their active state; now it will re-calculate the margin-top at the time of expansion as well.

@afercia Does the no-widget-areas-rendered-notice need some aria love?

The way I set up my test here was just to make this change to twentyfifteen to cause the widget area to not appear on the homepage:

  • src/wp-content/themes/twentyfifteen/sidebar.php

    if ( has_nav_menu( 'primary' ) || has_nav_menu( 'social' ) || is_active_sidebar( 
    3636                        </nav><!-- .social-navigation -->
    3737                <?php endif; ?>
    39                 <?php if ( is_active_sidebar( 'sidebar-1' ) ) : ?>
     39                <?php if ( ! is_front_page() ) : ?>
    4040                        <div id="widget-area" class="widget-area" role="complementary">
    4141                                <?php dynamic_sidebar( 'sidebar-1' ); ?>
    4242                        </div><!-- .widget-area -->

#7 @westonruter
9 years ago

  • Owner set to westonruter
  • Status changed from reopened to accepted

#8 follow-up: @afercia
9 years ago

@westonruter do you mean something to convey a sort of "alert" meaning? Hm, I'd keep it simple and maybe just use a <em> instead of a <div> and remove font-style: italic; and use display: block;

Adding a screenshot of the notice :)

Last edited 9 years ago by afercia (previous) (diff)

#9 in reply to: ↑ 8 ; follow-up: @westonruter
9 years ago

Replying to afercia:

@westonruter do you mean something to convey a sort of "alert" meaning? Hm, I'd keep it simple and maybe just use a <em> instead of a <div> and remove font-style: italic; and use display: block;

So no role=alert or anything like that?

#10 in reply to: ↑ 9 @afercia
9 years ago

Replying to westonruter:

So no role=alert or anything like that?

The role=alert is a bit tricky, browsers and assistive technologies support is still inconsistent especially when the alert element is created on the fly, see See also Mr. Craig's comment and following discussion on that post. We struggled a bit to make it work in the best possible way in #32600.

If we really want to deliver an alert maybe we should try to use what we already have and use wp.a11y.speak( message, 'assertive' ) when the panel opens, maybe passing a shorter message :) By the way I'm not sure it would help so much, maybe we'd better let users explore the content and get the displayed message.

#11 @westonruter
9 years ago

OK, it's now using an em in 33052.2.diff.

@valendesigns Can I get some support with testing/review?

#12 follow-up: @valendesigns
9 years ago

@westonruter Sure thing. Is this patch duplicating the top margin code or replacing it?

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

9 years ago

#14 in reply to: ↑ 12 @westonruter
9 years ago

Replying to valendesigns:

@westonruter Sure thing. Is this patch duplicating the top margin code or replacing it?

Sorry, I missed this. It should be extracting the margin-top code into a separate method that only gets attached once instead of being re-attached with each reflow.

#15 @westonruter
9 years ago

Defect #33567 is dependent on the patch in this ticket, and I've amended the patch to include the fix for it: 33052.3.diff

#16 @westonruter
9 years ago

Qunit tests are broken with this patch.

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

9 years ago

#18 @westonruter
9 years ago

  • Keywords needs-unit-tests removed

Fixed unit tests in 33052.4.diff.

#19 @westonruter
9 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 35231:

Customizer: Always show Widgets panel initially if sidebars are registered; show notice to users in panel if no widget areas are in current preview.

Widgets panel will not wait to display until the preview loads.

Also fixes problems with margin-top in panels where other panels' active states change, as well as ensuring sections of deactivated panel collapse before panel is hidden to prevent the pane from becoming empty of controls.

Fixes #33052.
Fixes #33567.

#20 @westonruter
9 years ago

In 35236:

Customizer: Add unit test for WP_Customize_Widgets::is_panel_active().

See #33052.

#21 @westonruter
7 years ago

In 40312:

Customize: Show notice in Widgets panel when there are additional widget areas not rendered in preview.

This extends the existing behavior which only showed a message only when there were no widget areas rendered in the preview. The number of non-rendered widget areas is indicated. Also removes needles deletion of property which hindered plugins.

See #33567, #33052.
Fixes #39087.

#22 @westonruter
7 years ago

In 40330:

Customize: Improve i18n for strings in hidden widget area notices.

Amends [40312].
Props westonruter, ocean90, swissspidy, SergeyBiryukov, michelleweber for copywriting.
See #33567, #33052.
Fixes #39087.

Note: See TracTickets for help on using tickets.