Make WordPress Core

Opened 10 years ago

Last modified 6 years ago

#25419 new enhancement

Add icon support for widgets on the admin page and customize screens

Reported by: westonruter's profile westonruter Owned by:
Milestone: Future Release Priority: low
Severity: minor Version: 3.9
Component: Widgets Keywords: has-ui-feedback 2nd-opinion dev-feedback has-patch needs-testing needs-refresh
Focuses: ui, administration Cc:

Description (last modified by westonruter)

With the incorporation of live widget previews (widget customizer), an available widget browser is displayed which lists all widgets along with a dashicon for each. These icons should be incorporated into the widgets admin page now, as well.

Attachments (5)

25419.patch (407.3 KB) - added by eherman24 10 years ago.
test_widget_icon_plugin.zip (3.9 KB) - added by eherman24 10 years ago.
simple plugin creating a widget to test out icons
25419.2.patch (407.4 KB) - added by eherman24 10 years ago.
Updated padding between icon and widget title (if icon exists)
25419.3.patch (407.5 KB) - added by eherman24 10 years ago.
decrease padding between icon and text in apperance > customizer screen
25419.4.patch (2.2 KB) - added by eherman24 10 years ago.
fixed whitespace issues, removed filter_var for esc_url, removed minified css files

Download all attachments as: .zip

Change History (27)

#1 @shaunandrews
10 years ago

  • Cc shaun@… added

#2 @westonruter
10 years ago

Work has started for this feature in the Widget Customizer plugin and the Better Widgets plugin.

#3 @westonruter
10 years ago

We'll be able to override the default wp_widget_control output to add support for the icons when #26661 is implemented.

#4 @westonruter
10 years ago

Actually, perhaps there will be no need for the icon to be indicated with PHP at all. If using Dashicons, then the font and icon can be purely defined in CSS. So this ticket would be primarily about providing a space for this icon to be displayed, to come up with default icons for core widgets, and to come up with a default icon which can then be overridden with a plugin's stylesheet. A plugin just need to enqueue a stylesheet to appear on the widgets admin page and in the customizer.

See conversation at https://twitter.com/joemcasta/status/414937640970878976

See also https://github.com/x-team/wp-widget-customizer/issues/69

#5 @ocean90
10 years ago

  • Focuses ui administration added
  • Keywords needs-ui removed
  • Milestone changed from Awaiting Review to 3.9
  • Type changed from feature request to enhancement

Moving to 3.9 for #27112.

I don't think a screenshot is neccesary for a widget. As westonruter points out, icons can be defined via CSS. Do we have the space for an icon?

#6 @johnbillion
10 years ago

  • Keywords needs-patch ui-feedback added
  • Milestone changed from 3.9 to Future Release

#7 @westonruter
10 years ago

  • Description modified (diff)
  • Summary changed from Add support to widgets for icons and screenshots to Add widget icons from customizer to widgets admin page

#8 @westonruter
10 years ago

  • Version set to 3.9

@eherman24
10 years ago

#9 @eherman24
10 years ago

  • Keywords has-patch dev-feedback needs-testing needs-docs added; needs-patch removed
  • Summary changed from Add widget icons from customizer to widgets admin page to Add widget icons from customizer to widgets admin page and customizer

Hey Westonruter,

I had actually wrote about this a few months back on my blog, and towards the end proposed that a patch be added to core that would allow this feature (http://www.evan-herman.com/add-an-icon-to-a-wordpress-widget/#.U-OuB_ldXT8).

I began development on a plugin, and wanted to customize the plugin and brand it a bit further than was possible. I had created a custom widget, but wanted to include the company logo into the widget on the admin side. The main reason behind this thought was that there are so many Widgets available to a user, that it quickly becomes visually overwhelming.

Adding an icon to the widget would make it a lot easier to locate the widget, without much time spent reading each widget title. WordPress has allowed for icons in menu items for sometime now, and allowed us to include dashicons into menu items. Going off that thought , I began to look around for a solution.

The route that I ended up taking was through CSS customizations, adding a background image to the widget title.

After mulling it over a bit, I decided I wanted to take charge and submit the first patch to adding icon support to widgets, much in the same way that add_menu_page() allows for.

I've come up with what I believe to be a solid solution to this need.


I've written the patch to allow an extra argument (icon_url) to be passed through to __construct() when initializing your custom widget.

public function __construct( $id_base, $name, $icon_url, $widget_options = array(), $control_options = array() )

Initializing your widget with a dashicon would look like this:

function __construct() {
	parent::__construct(
		'foo_widget', // Base ID
		__('Widget With Icon', 'text_domain'), // Name
		'dashicons-admin-collapse' ,  // New Icon Param (dashicon)
		array( 'description' => __( 'Testing a widget with an icon', 'text_domain' ), )
	);
}



Dashicon Widget Icon Screenshots:
http://s30.postimg.org/pnqqmrsn5/widget_screen_widget_dashicon.jpg
http://s30.postimg.org/6u4xpruf5/widget_screen_active_widget_dashicon.jpg
http://s30.postimg.org/7orhbt29t/theme_customizer_widget_dashicon.jpg



Whereas initializing your widget with a custom image would be very similar, you would just pass in the path to the icon, much in the same way you do with add_menu_page() like this:

function __construct() {
	parent::__construct(
		'foo_widget', // Base ID
		__('Widget With Icon', 'text_domain'), // Name
		plugin_dir_url( __FILE__ ).'/image/yikes_logo_widget_icon.png' ,  // New Icon Param (image)
		array( 'description' => __( 'Testing a widget with an icon', 'text_domain' ), )
	);
}



Image Icons (.jpg,.png etc) Widget Icon Screenshots:
http://s30.postimg.org/psuhwfzy9/widget_screen_widget_image_icon.jpg
http://s30.postimg.org/dof8fgn29/theme_customizer_widget_image_icon.jpg



I took into consideration that some users ( or existing plugins/widgets ) may not want to use an icon or may not want to go back and add the new parameter. This is true for all of the default widgets (Archives, Tag Cloud etc.). So instead of going back and adding the new parameter to those already existing widgets, I've built in some backwards compatibility when parsing the code to prevent issues with existing widgets.

Adding icons to default widgets, or any widgets created by plugins would be as simple as going in and adding the new icon_url parameter just below the widget name.

Lets consider adding this feature into 4.0 or 4.1, as a way to unify the styles (and creation) between the admin and widget menus.

@eherman24
10 years ago

simple plugin creating a widget to test out icons

@eherman24
10 years ago

Updated padding between icon and widget title (if icon exists)

@eherman24
10 years ago

decrease padding between icon and text in apperance > customizer screen

#10 @eherman24
10 years ago

  • Summary changed from Add widget icons from customizer to widgets admin page and customizer to Add icon support for widgets on the admin page and customize screens

#11 @eherman24
10 years ago

  • Keywords 2nd-opinion added

#12 @ocean90
10 years ago

  • Keywords needs-patch added; has-patch dev-feedback needs-testing needs-docs 2nd-opinion removed

eherman24, thanks for your patch so far. Some feedback:

#13 @eherman24
10 years ago

ocean90, thanks for the feedback.

I guess I wasn't sure about the minified files being re-compiled, but thanks for the clarification.

In regards to backwards compatibility, Pre-patch, the constructor passes in the $option->name (string) in that argument location. With the new patch, I'm passing in an array and checking if the returned argument is indeed an array. Is this not a viable way to go about doing things? I tested against previous versions of WordPress and things appeared to be backwards compatible with the new patch.

$this->icon_url = is_array($icon_url) || empty($icon_url) ? '' : $icon_url; // create the icon url parameter

And noted on the white space, I'll have a second go at this and fix the issues you have pointed out.

Thanks,
Evan

Last edited 10 years ago by eherman24 (previous) (diff)

@eherman24
10 years ago

fixed whitespace issues, removed filter_var for esc_url, removed minified css files

#14 @eherman24
10 years ago

  • Keywords 2nd-opinion dev-feedback added

I've attached a new patch which excludes the minified files, fixes white spacing issues and swaps out filter_var for esc_url.

I am still open to hearing suggestions about the best way to handle the $icon_url argument within the constructor.

Evan

#15 @eherman24
10 years ago

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

#16 @wonderboymusic
9 years ago

  • Keywords needs-refresh added

$icon_url can be part of $widget_options

#17 @FolioVision
8 years ago

Tested the styling with dashicons, the spacing looks fine in narrow columns, on mobiles, with accessibility mode.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 years ago

#19 @karmatosed
7 years ago

  • Priority changed from normal to low

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


6 years ago

#21 @karmatosed
6 years ago

  • Keywords has-ui-feedback added; ui-feedback removed

#22 @joyously
6 years ago

Design-wise, I am against the whole notion of putting icons on widgets. I have had several conversations with people recently that make me think that it's the younger folks that like them. The middle-aged and older set have a difficult time deciphering their meanings, and prefer text.
Icons add visual clutter with no real benefit, and can overwhelm.

Instead of icons, I would suggest to improve the widget UI by making the arrow that collapses and expands the Available Widgets column visible all the time, instead of just on hover. And by showing the Inactive Widgets in the Customizer.

Note: See TracTickets for help on using tickets.