Make WordPress Core

Opened 11 years ago

Closed 9 years ago

#26922 closed enhancement (maybelater)

WP-Admin - Allow for Additional Icon Fonts

Reported by: styledev's profile styledev Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.8
Component: Administration Keywords:
Focuses: Cc:

Description

Currently, register_post_type allows the custom post type to set their menu icon via URL, a data string, or use Dashicons. It would be great to allow for the Developer to add in their own icon font (e.g. Symbolset).

To do so would require the addition of two new filters and a small rework of the current code in menu-header.php and menu.php. The goal here is to allow for the similar functionality that allows "dashicons-" to work.

I will attach a patch next.

Attachments (1)

admin-icon-fonts.26922.diff (2.6 KB) - added by styledev 11 years ago.
Patch to add filters to allow for new icon fonts.

Download all attachments as: .zip

Change History (9)

#1 follow-up: @nacin
11 years ago

Hi styledev. I think the best step here would be to pass 'none' and then use CSS to add the icon yourself, versus adding more PHP into the mix. SVG benefits from HTML changes, and Dashicons is part of WordPress so it made sense for a special exemption/feature there, but I don't think leaving this to CSS for non-SVG non-Dashicons is much of an issue.

As an aside, I'm not sure we'd want to encourage alternative iconsets, as it would be tough to maintain a consistent design that way. Ideally, icons are either a Dashicon or a custom SVG designed with the same aesthetic. This has the added benefit of being "painted" the right color depending on the color scheme in use.

#2 @nacin
11 years ago

  • Component changed from Graphic Design to Administration

@styledev
11 years ago

Patch to add filters to allow for new icon fonts.

#3 in reply to: ↑ 1 @styledev
11 years ago

Hey nacin,

Replying to nacin:

Hi styledev. I think the best step here would be to pass 'none' and then use CSS to add the icon yourself, versus adding more PHP into the mix. SVG benefits from HTML changes, and Dashicons is part of WordPress so it made sense for a special exemption/feature there, but I don't think leaving this to CSS for non-SVG non-Dashicons is much of an issue.

I see what you mean but by passing 'none' you then have to painstakingly add in additional css. This method allows you to just state for instance 'ss-user' and as long the icon set is enqueued properly it works very nicely.

As an aside, I'm not sure we'd want to encourage alternative iconsets, as it would be tough to maintain a consistent design that way. Ideally, icons are either a Dashicon or a custom SVG designed with the same aesthetic. This has the added benefit of being "painted" the right color depending on the color scheme in use.

As it stands, we (developers) are already adding in different icons into wp-admin and have been doing so for a long time. So I argue that It is up to the developer to maintain the consistent design for their end-user and in some cases maybe their end-user doesn't care if it is not consistent.

It was already a challenge to find enough icons that fit the old look and feel. Now with the "flat-design" and the growing number of icon fonts out there it is much easier to match the icons than before. As you can see below, Symbolset fits nicely into wp-admin and works with the variety of color palette choices.

http://parapxl.com/wp/wp-admin-symbolset-icon-font.jpg

Last edited 11 years ago by styledev (previous) (diff)

#4 follow-up: @melchoyce
11 years ago

At some point Till Kruess wrote up a guide for using an alternate icon font:
https://github.com/tillkruess/MP6-Icon-Examples/blob/master/mp6-font-icon.php

I was able to tweak it enough to work in a CPT. I think this was what I ended up with inside my CPT class:

function __construct() {
	add_action( 'admin_enqueue_scripts', array( $this, 'enqueue_[CPT]_styles'  ) );
	add_action( 'admin_head', array( $this, 'set_custom_font_icon' ) );
}

function enqueue_[CPT]_styles() {
	wp_enqueue_style( '[CPT]-font',  plugins_url( 'css/[CPT]-font.css', __FILE__ ), array(), $this->version );
}

/**
 * Custom CPT Icon CSS
 */
function set_custom_font_icon() {
?>
    <style type="text/css">
        #menu-posts-[CPT]_menu_item .wp-menu-image:before {
            font-family: '[CPT]-font' !important;
            content: '\e603' !important;
        }
    </style>
<?php
}

#5 in reply to: ↑ 4 @styledev
11 years ago

Replying to melchoyce:

At some point Till Kruess wrote up a guide for using an alternate icon font:
https://github.com/tillkruess/MP6-Icon-Examples/blob/master/mp6-font-icon.php

I was able to tweak it enough to work in a CPT. I think this was what I ended up with inside my CPT class:

function __construct() {
	add_action( 'admin_enqueue_scripts', array( $this, 'enqueue_[CPT]_styles'  ) );
	add_action( 'admin_head', array( $this, 'set_custom_font_icon' ) );
}

function enqueue_[CPT]_styles() {
	wp_enqueue_style( '[CPT]-font',  plugins_url( 'css/[CPT]-font.css', __FILE__ ), array(), $this->version );
}

/**
 * Custom CPT Icon CSS
 */
function set_custom_font_icon() {
?>
    <style type="text/css">
        #menu-posts-[CPT]_menu_item .wp-menu-image:before {
            font-family: '[CPT]-font' !important;
            content: '\e603' !important;
        }
    </style>
<?php
}

Right, this is what is required to use your own icon font currently. While I get that we can do this it would be nicer/easier if we could just provide the ability to add the css classes that already come with the font.css instead of having to write out the content call every time for each menu item in a css file which is separate from the register_post_type call. For the example image above you would be writing out 4 lines of css times 11 for a total of 44 lines instead of just calling 'prefix-iconName'. Also, by using the unicode/glyph content it is not intuitive as to what icon is what when you are in there.

My thinking is we are already handling one icon font prefix for dashicons, why not expand the code a little to handle any prefixes?

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


11 years ago

#7 @styledev
11 years ago

  • Keywords has-patch dev-feedback added

#8 @chriscct7
9 years ago

  • Focuses ui removed
  • Keywords has-patch dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

No further interest in 2 years. Closing as maybelater. Feel free to reopen if interest re-emerges

Note: See TracTickets for help on using tickets.