Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#30971 closed enhancement (fixed)

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

Reported by: celloexpressions's profile celloexpressions Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 4.2 Priority: normal
Severity: normal Version: 3.9
Component: Customize Keywords: good-first-bug has-patch commit
Focuses: ui Cc:

Description

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.

Attachments (3)

2015-01-10 at 9.30 AM.png (260.3 KB) - added by caseypatrickdriscoll 10 years ago.
Description of Widgets Link
2015-01-10 at 9.42 AM.png (241.4 KB) - added by caseypatrickdriscoll 10 years ago.
Destination
admin-bar.diff (1.4 KB) - added by caseypatrickdriscoll 10 years ago.
patch

Download all attachments as: .zip

Change History (15)

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


10 years ago

@caseypatrickdriscoll
10 years ago

Description of Widgets Link

#2 @caseypatrickdriscoll
10 years ago

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.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


10 years ago

#4 @celloexpressions
10 years ago

  • Owner set to caseypatrickdriscoll
  • Status changed from new to assigned

Comments left on Slack.

#5 @celloexpressions
10 years ago

  • Keywords has-patch commit added; needs-patch removed
  • Owner caseypatrickdriscoll deleted

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.

#6 @SergeyBiryukov
10 years ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from assigned to closed

In 31176:

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

props caseypatrickdriscoll.
fixes #30971.

#7 @pavelevap
10 years ago

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

#8 @SergeyBiryukov
10 years ago

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.

#9 @brit77
9 years ago

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!

#10 @jb510
9 years ago

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

#11 @SergeyBiryukov
9 years ago

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

#12 @jb510
9 years ago

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)

Note: See TracTickets for help on using tickets.