Widgets link in front-end admin bar should point to Widgets in the Customizer

[celloexpressions]

The Customizer is primarily useful for front-end-contextual changes. Widget Customizer embraces front-end context by only showing active widget area

The Widgets link in the front-end admin bar should point to the widgets panel in the Customizer instead of the widgets admin page because of the front-end context that the Customizer provides. This would not effect links to the Widgets admin page from anywhere in the admin.

The new link needs to have query args for both the url and to autofocus to the widgets panel, see the adjacent header/background links for this pattern. It also needs to be .hide-if-no-customize, with the current link being retained with the addition of the .hide-if-customize class.

[caseypatrickdriscoll]

Description of Widgets Link

[caseypatrickdriscoll]

Is this about correct @celloexpressions?

This is my first contribution and I'd like to own/complete this today.

From what I can tell there isn't an 'autofocus' GET controller for every component. For example &autofocus[control]=colors doesn't open the 'colors' panel. Not sure if that is a secondary ticket or not.

[caseypatrickdriscoll]

Destination

[celloexpressions]

Comments left on Slack.

[caseypatrickdriscoll]

patch

[celloexpressions]

Patch looks good and works as intended.

Note that there may be some issues with the vertical positioning inside the widgets panel when it loads. That's a separate, existing (known) issue with panels.

[SergeyBiryukov]

In 31176:

Customizer: Use deep-link for Widgets in toolbar on front-end.

props caseypatrickdriscoll.
fixes #30971.

[pavelevap]

What about Welcome panel? There is also link to Widgets admin page...

[SergeyBiryukov]

Yep, also in the active theme modal on Themes screen.

I think those should still link to the admin screen, as they don't have a front-end context, as mentioned in the ticket description.

[brit77]

Perhaps it is too late to comment on this, but I just discovered this change.

In practice, I'm finding the Widget Customizer to be sluggish and inefficient: first loads the main Customize panel, then a few seconds later switches to the Widget panel; exiting out takes a couple of clicks and several seconds too.

There is already a link in the appearances drop-down to open the Customizer (and even with the extra click, it's no slower than opening the Widgets panel from the link), so is it really necessary to also open widgets in the Customizer?

The alternative route to the widgets page in admin is three clicks: Dashboard>(scroll down) Appearances>Widgets...time consuming, but maybe still quicker than using the Customizer! Even better to have the shortcut directly to the page.

Having Themes open in the Customizer makes more sense; themes aren't frequently changed. Widgets however may be accessed much more often. And as noted, there is an option already from the admin panel to access Customize>Widgets. Do we really have to lose the convenient shortcut to the Widgets page? :(

I frequently access the widget page, and I've tried to acclimate to the Customizer, but it is really slowing me down. Please, I'd like to see a solution! I have found no plugin or help file to address this, so I'm turning to you good people to see what you have to say.

Thanks!

[jb510]

Ditto, on probably being too late, but this is causing real problems for me on a few sites.

In most cases it's just not at all where I want to manage widgets because it's slow and confusing. In those I'm just annoyed by the change, but that's tolerable.

On a few sites however the customizer doesn't even load. Instead I get the sidebar and just get a pinwheel in the main window. This is beyond the annoyance, it's failure. I don't know why, don't really care these are old and very large sites with no need to ever use the customizer.

In more than one case this change has left a client totally confused because until now they had no idea the customizer even existed and they have no idea how to use it.

I did a walk through with one of them and I see why they're confused. First they assumed they could now drag and drop actual widgets around on the front end (ie. drag/drop in the main window), they they basically ignored the sidebar at first. Then upon realizing they couldn't do what they expected, they figured it still worked the way they were used to and started trying to drag widgets from the sidebar onto the main window.

Anyway, too late just logging it. Not sure why I didn't notice this testing 4.2, seems like I only noticed this after 4.2.2

[SergeyBiryukov]

Here's a snippet to restore non-Customizer links to themes and widgets in the toolbar:

function wp30971_replace_themes_and_widgets_links_in_admin_bar( $wp_admin_bar ) {
	if ( current_user_can( 'switch_themes' ) ) {
		$wp_admin_bar->remove_menu( 'customize-themes' );

		$wp_admin_bar->add_menu( array(
			'parent' => 'appearance',
			'id'     => 'themes',
			'title'  => __( 'Themes' ),
			'href'   => admin_url( 'themes.php' ),
			'meta'   => array(
				'class' => '',
			),
		) );
	}

	if ( ! current_user_can( 'edit_theme_options' ) ) {
		return;
	}

	if ( current_theme_supports( 'widgets' )  ) {
		$wp_admin_bar->remove_menu( 'customize-widgets' );

		$wp_admin_bar->add_menu( array(
			'parent' => 'appearance',
			'id'     => 'widgets',
			'title'  => __( 'Widgets' ),
			'href'   => admin_url( 'widgets.php' ),
			'meta'   => array(
				'class' => '',
			),
		) );
	}
}
add_action( 'admin_bar_menu', 'wp30971_replace_themes_and_widgets_links_in_admin_bar', 100 );

[jb510]

Thanks you @SergeyBiryukov! I had just started looking into writing that code myself when I found this ticket, awesome now I don't have to write it! Adding this to my default mu-plugin that also adds a menu link to /wp-admin/plugins.php (which is, by far, the place I need to go directly in the backend most often when I'm on the front end)