Widgets section in customize late to show up

[kidsguide]

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

​https://www.youtube.com/watch?v=JHDuITWULN8

[westonruter]

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.

[kidsguide]

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

[westonruter]

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.

[westonruter]

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

[westonruter]

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.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/123

[westonruter]

See 33052.diff​.

Video demo: ​https://cloudup.com/cHEat_4UK91

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(){ 
    wp.customize.control('background_color').focus(); 
}})

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

@@ -36 +36 @@
                         </nav><!-- .social-navigation -->
                 <?php endif; ?>
 
-                <?php if ( is_active_sidebar( 'sidebar-1' ) ) : ?>
+                <?php if ( ! is_front_page() ) : ?>
                         <div id="widget-area" class="widget-area" role="complementary">
                                 <?php dynamic_sidebar( 'sidebar-1' ); ?>
                         </div><!-- .widget-area -->

[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;

Adding a screenshot of the notice :)

[westonruter]

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?

[afercia]

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 ​https://www.paciellogroup.com/blog/2012/06/html5-accessibility-chops-aria-rolealert-browser-support/ 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.

[westonruter]

Additional change: ​https://github.com/xwp/wordpress-develop/commit/25de145e7dde5054592fdd28eec766a3fad8f801

[westonruter]

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

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

[valendesigns]

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

[westonruter]

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.

[westonruter]

Additional change: ​https://github.com/xwp/wordpress-develop/commit/3c1233199fca3e018e103575bdf13c8c410032d4

[westonruter]

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​

[westonruter]

Qunit tests are broken with this patch.

[westonruter]

Additional change: ​https://github.com/xwp/wordpress-develop/commit/b1fc48b6408cd451cc9ad49e498efb4228ee6594

[westonruter]

Fixed unit tests in 33052.4.diff​.

[westonruter]

Additional change: ​https://github.com/xwp/wordpress-develop/commit/c9ba977fbed9f3b42dceea313879b6c39903e2be

[westonruter]

Additional changes: ​https://github.com/xwp/wordpress-develop/compare/5f8cbdfc9dd7d6d7344924898fa37ddb0bf8da3d...83ba8697da2e34d815c7aa5563f3641a7ec29a83

[westonruter]

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.

[westonruter]

In 35236:

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

See #33052.

[westonruter]

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 wp.customize.Widgets.data.l10n property which hindered plugins.

See #33567, #33052.
Fixes #39087.

[westonruter]

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.