WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#27290 closed enhancement (maybelater)

Use Widget Customizer for "Widgets" link in front-end-toolbar appearance menu

Reported by: celloexpressions Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9
Component: Widgets Keywords:
Focuses: ui Cc:

Description

Now that we can manage widgets in the customizer, the fastest, most contextual way to edit widgets is in the customizer. Thus, when wanting to edit a widget and being on the front-end, the widget customizer is more likely to be more suitable than the standalone widgets screen, since the front-end context is maintained.

In the context of the admin, the existing widgets screen will often be more appropriate than the customizer for many users, but in the front-end context that is not the case. By removing the link to the old widgets page on the front-end toolbar, users are nudged to try the customizer instead (and could easily discover that widgets can now be managed there in the process), and there is one less link in what can be a long list when the custom header and background features are in use. As more "appearance" features are moved to the customizer and potentially removed from this menu, we could look at adding other non-appearance admin quick-links there.

"Remove" functionally means "hide" here, as the customizer isn't always available.

Attachments (2)

27290.diff (2.2 KB) - added by celloexpressions 8 years ago.
Add hide-if-customize class to "Widgets" menu item in front-end toolbar appearance sub-menu; fix spacing/coding standards
27290.2.diff (2.5 KB) - added by celloexpressions 8 years ago.
Use a widget customizer link when the customizer is available, otherwise use the existing link. Also fixes spacing.

Download all attachments as: .zip

Change History (10)

@celloexpressions
8 years ago

Add hide-if-customize class to "Widgets" menu item in front-end toolbar appearance sub-menu; fix spacing/coding standards

#1 @celloexpressions
8 years ago

  • Keywords has-patch added

Patch also fixes the spacing/line breaks of that set of toolbar menu additions to match the rest of admin-bar.php, and switches to the current coding standards. Functional diff is just the addition of the hide-if-customize class.

#2 follow-up: @westonruter
8 years ago

Note there is also a "deep link" URL into the customizer now to automatically expand the first widget area section of the customizer: /wp-admin/customize.php?widget-customizer=open. This URL could be used as the link for the Widgets menu item in the admin bar, if it is determined that the browser supports the customizer.

Originally proposed in https://github.com/x-team/wp-widget-customizer/issues/32

@celloexpressions
8 years ago

Use a widget customizer link when the customizer is available, otherwise use the existing link. Also fixes spacing.

#3 in reply to: ↑ 2 @celloexpressions
8 years ago

  • Summary changed from Remove "Widgets" from front-end-toolbar appearance menu, in favor of Widget Customizer to Use Widget Customizer for "Widgets" link in front-end-toolbar appearance menu

Replying to westonruter:

Note there is also a "deep link" URL into the customizer now to automatically expand the first widget area section of the customizer: /wp-admin/customize.php?widget-customizer=open. This URL could be used as the link for the Widgets menu item in the admin bar, if it is determined that the browser supports the customizer.

The question then is "which widget area"? But I could see this working even better.

Basically, using a widgets link that opens the customizer would cause users to potentially discover the entire customizer, while removing the separate widgets link would force users to see what the other links did (such as the customize link). For now, a separate widgets link makes more sense, to ease the transition into managing more of the site from the customizer. When menus, background, header, and theme-switching are all fully incorporated into the customizer in the future, we could probably drop this whole menu in favor of a more prominent customizer link. But as we build it out over time, deep-linking seems like a good approach.

New patch uses the widget customizer link when the customizer is available, and the old widgets link when the customizer isn't available (so that those users still get the link). This seems like a great way to seamlessly introduce users to this new feature.

This ticket was mentioned in IRC in #wordpress-dev by celloexpressions. View the logs.


8 years ago

This ticket was mentioned in IRC in #wordpress-dev by celloexpressions. View the logs.


8 years ago

#6 @ocean90
8 years ago

In 27891:

Widget Customizer: Remove WidgetCustomizer.showFirstSidebarIfRequested().

It's currently unused and needs another iteration.

see #27290.

#7 @celloexpressions
8 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

If we'd done this it wouldn've needed to happen in 3.9 with the launch of the Widget Customizer. At this point it's probably better to just wait until we're ready to replace the entire Appearance section with the Customizer, which would require iterations of backgrounds and widgets (to include all features of their respective screens) and the addition of themes and menus to the customizer. Once everything's eventually in, it'll be easier to push users directly into the Customizer without messing with things like deep-linking.

#8 @ocean90
8 years ago

  • Keywords has-patch removed
  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.