Show icon on icon_selector dropdown list

Because I thought the method of selecting icons was a weak point of this otherwise great module, I created a small add-on module that allows you to select the icons in a more visual way. The module can be found in my sandbox.
Maintainers feel free to embed my code in your project, if you like the solution.

@K3vin, thanks for the code to peek over :)

This is definitely something that I had planned to design more with early on. Unfortunately I never was able to see this aspect of the module to fruition.

Ultimately I had envisioned something a little more interactive (like a modal) that would allow you to focus on individual bundles, search all/specific bundles, choose from variations/sizes/versions, etc.

Obviously all those features wouldn't be done by this issue alone, but I do need to mention them so you can see where I was planning to go with this and what kind of expectations I have with this issue.

It would also need to load these icons in an iframe (for theme/font based icons) if the bundle providing it wasn't the current theme. In reality though it's likely just better to do an iframe for everything so there aren't any CSS selectors/stylesheets that conflict between different bundles.

I did briefly take a look at the sandbox, but I would be more interested in patches against this module instead though. I rarely have the time to do in-depth overviews of independent projects and then trying to decipher what it is attempting to override.

Mark, I will try to create a patch against the current version for you to review tonight.
I'm not sure I understand 'It would also need to load these icons in an iframe (for theme/font based icons) if the bundle providing it wasn't the current theme.'
How are the icon bundles related to the theme? And how could CSS selectors/stylesheets conflict between different bundles?

How are the icon bundles related to the theme?

The Drupal Bootstrap base-theme provides Glyphicon support via the fonts that are imported with the CSS of the theme: ./includes/icons.inc and _bootstrap_glyphicons(). If the admin theme isn't Bootstrap based (or a different version of Bootstrap) then the icons wouldn't necessary show up (because that theme's CSS hasn't been loaded).

And how could CSS selectors/stylesheets conflict between different bundles?

This can happen, albeit rather rarely. It has more to do with the dynamic sub-modules like Fontello and IcoMoon which allow people to import the archives they download from these services. Considering that one could, in theory, have multiple bundles on a site; there is definitely a strong possibility of potential naming collisions.

Especially depending on the client requirements. I know, because I have done it. I have had a client that wanted icons to show up in all these sections of the site, but "slightly" modified per each section. The easiest way to do this (given their existing architecture) was to load a unique "bundle" for each section. This allowed us to kept the markup and classes the same, but independently show "different" icons by simply assigning a specific bundle to be loaded per section. So, because all of these bundles had the same icon "name", loading each and every bundle on one page wouldn't work at all.

The same principle really applies to something like an "Icon Selector" plugin/widget though. It will most definitely need to be sandboxed so it can load whatever additional external assets that are necessary, without the risk of any potential conflicts.

Thanks for the explanation Mark. I'll first do some more work and testing in my sandbox before submitting a patch.

FYI: Select2 allows icons to be placed in drop-down menus. There is a module already that you can utilize: Select2 Field Widget

I'd really rather not have to involve Select2 if I can avoid it.

Subscribing to this, and declaring my intent to look into a solution for this in the near future as Wysiwyg Fields uses the Icon API module for icon selection of Wysiwyg field CKEditor button icons, and a preview would make things much simpler for site builders.

I wanted to point out a beautiful icon picker here:
http://mjolnic.com/fontawesome-iconpicker/

Despite being called font awesome icon picker it does allow other font icons sets.

There is a project for it here:
https://www.drupal.org/project/fontawesome_iconpicker

It is nice, definitely worth looking at as a potential solution.

Look again at that issue pedrosp -- the maintainer has a patch to make it work with Icon API now.

The fontawesome-iconpicker is indeed really nice. I will likely use it on some my own projects. However, along with my sentiments of #7, I would like to try an avoid any extra dependencies. The fontawesome-iconpicker is obviously for bootstrap based themes. We need a self-contained solution that would work on any theme.

FWIW though, fontawesome-iconpicker is almost exactly what I had in mind for this type of UI enhancement.

I did some more work on my project, but I ran into some more issues / challenges:

• I use an icon field in panel style display. The configuration for these styles are rendered by ctools, making it difficult to attach javascript or css to a field, since ctools renders the form elements differently.
• The icon api block submodule also renders a variant with additional options.

It is difficult to make a general solution that works in all cases. I agree with Markcarver that a solution that opens a popup/modal might be the best solution.

It occurs to me that the CSS icons cause a limitation for this module, not only do they make it hard to reuse an existing JavaScript icon picker, they cause other limitations; Wysiwyg Fields for instance provides icons to CKEditor, but only physical icons can be used.

As such, I propose that we focus on a method of extracting CSS based icons. I already have a module that takes large images and cuts then down (deepzoom) which it's code could potentially be adapted, but I don't doubt that there is a code snippet that does exactly what we need already.

Yes, which is what I was alluding to with having to use IFRAMES in #2. That is the only way I can see this module properly working. Have a picker that loads each bundle separately in its own IFRAME and then use JS to communicate selections back to the picker.

So I was originally thinking of Sprites, but of course that would be too easy, Bootstrap and Fontawesome, are of course, Fonts.

I know that Bootstrap comes with an SVG, and I did find the following library that could potentially be used for that: https://github.com/blacksunshineCoding/svgFontReader

Will try to do some playing over the weekend.

Edit: Confirmed that FontAwesome also has a SVG file.

I really don't want to get into the business of trying to "read" SVG files. Static images and SVG files can be displayed normally. The burden of this issue is really around supporting sprite and font based icons. I think if a bundle is theme based, we just need to load the theme so the icons will show up. That's why I'd much rather treat each bundle as a "sandbox" in an IFRAME, so to speak, and not have to worry about it.

edit: Regardless if a font based icon set originally comes with SVG files, they cannot be relied on. A Bootstrap theme can be CDN based, which utilizes the fonts. Trying to parse the source files, when it may or may not exist, is a nonstarter IMO.

While the "sandbox" IFRAME approach might work for the picker to prevent style conflicts, if someone where to choose a theme based icon that wasn't from the theme they are personally using (Bootstrap bundle Icon on non-Bootstrap custom theme) you are still going to have the same potential style conflicts.

If you where to have Icon API provide custom CSS purely for the intent of mapping icon classes to an icon based font, then you wouldn't need to worry about sandboxing.

I'm not saying this will be easy, but the issues isn't a easy issue.

Another approach would be to put requirements on Icon bundles, or categories as I mentioned in https://www.drupal.org/node/2547193#comment-10194163, which would allow you to restrict the icon selection choice based on the theme.

if someone where to choose a theme based icon that wasn't from the theme they are personally using (Bootstrap bundle Icon on non-Bootstrap custom theme) you are still going to have the same potential style conflicts.

Yes. This is essentially what #2 is in reference to: node edits (where the icon_selector will likely appear) can happen in an admin theme which is likely not Bootstrap based (e.g. seven, rubik, adminimal_theme).

Currently the icon list is just populated as a <select> list, so there wasn't really any need to filter it based on the active theme. The list of available icons is solely based on if a theme is enabled (icon_enabled_themes()) and has the proper icon[s].inc file and hooks. In hindsight, yes, it should filter based on default theme. That is why we're discussing it here.

So, since an icon "bundle" has different render "types", this API should strive to support the delivery of these bundles with minimal assumptions or extraneous code. A generalized approach (iframe sandbox) is likely the only way it will work (properly). This will reduce the amount of overhead it would normally take to deal with said conflicts (fillenames, class names, prefixes, etc.).

Ultimately, we would likely have to restrict theme based bundles based on the current value of the theme_default variable (and it's inherited base themes).
This can also get rather hairy when dealing with multi-sites/domains that share a common core, but not necessarily the same DB. Again, another reason sandboxing via an iframe is likely the only solution here.

The way I imagined this is that we use the same menu callback we use for listing the icons in an iframe, so it can use the proper theme callback: icon_bundle_get_theme().

If you where to have Icon API provide custom CSS purely for the intent of mapping icon classes to an icon based font, then you wouldn't need to worry about sandboxing.

No, this is an API. It is meant to map existing data. I do not want to start generating new content just for management sake. This leads to more problems than it's worth in the long run (e.g. parsing, aggregation, cache invalidation, file management). And, again, it doesn't address Bootstrap based themes that are using a CDN with no physical sources on disk to parse.

No, this is an API. It is meant to map existing data. I do not want to start generating new content just for management sake. This leads to more problems than it's worth in the long run (e.g. parsing, aggregation, cache invalidation, file management). And, again, it doesn't address Bootstrap based themes that are using a CDN with no physical sources on disk to parse.

Not at all suggesting that Icon API define the maps, rather that it leverages existing maps where possible; http://codeb.it/fonticonpicker/ uses config.json from Fontello and selection.json from IcoMoon, it's more than possible that there is already something available for FontAwesome and Glyphicons as well. It could be built into the API for font based Icons to provide their map.