To increase the flexibility of this module, it would be ideal if all icon packs where available in a physical file format; Currently packs such as Bootstrap and Fontawesome have the icons as fonts, which prevents certain usecases such as Wysiwyg Fields which exposes Icons to CKEditor, but CKEditor requires a physical file.

There is potential to use something like https://github.com/blacksunshineCoding/svgFontReader/blob/master/svgFont... to extract the icons from the SVG font sources.

Comments

Deciphered created an issue. See original summary.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Active » Closed (won't fix)
Related issues: +#1934250: Add CKEditor plugin to use with icon_filter sub-module

See comment https://www.drupal.org/node/2370899#comment-10193953

Also, I do not like the idea of having a dependency for this module, which is strictly an API.

Wysiwyg Fields which exposes Icons to CKEditor, but CKEditor requires a physical file.

I really haven't looked at Wysiwyg Fields TBH, but I know that CKE doesn't require a physical file. I've done a lot of integration with CKE and Bootstrap (most internal and not public) and it really just boils down to ensuring that the front facing theme is loaded inside CKE so the tags with the appropriate icon classes show up.

Because of this, that means there would be (or rather should be) a restriction for which theme based icon bundle is available. However, due to the complex nature of CKE and font based icons, this module hasn't gotten very far.

This is why I had originally created #1934250: Add CKEditor plugin to use with icon_filter sub-module. Trying to "load" icons in a WYSIWYG can be very complex. Given that CKE has "widgets" now, it is (in theory) possible to also silo these "icons" in their own IFRAMEs, but I'm not entirely sure how well that will play out. Regardless, this area (WYSIWYG/CKE) isn't really where I feel this module should be focused right now. There are a lot of other issues that need to be addressed (like the icon picker, which could be used outside of CKE).

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Closed (won't fix) » Needs review

Also, I do not like the idea of having a dependency for this module, which is strictly an API.

I'm also not suggesting adding a dependency, if you look at the reference file it's just a very small snippet of code, I would be writing the code natively into Icon API.

I really haven't looked at Wysiwyg Fields TBH, but I know that CKE doesn't require a physical file. I've done a lot of integration with CKE and Bootstrap (most internal and not public) and it really just boils down to ensuring that the front facing theme is loaded inside CKE so the tags with the appropriate icon classes show up.

I think you misunderstand the use case. Wysiwyg Fields uses the Icon for a CKEditor native plugin, which does require a physical file.

Because of this, that means there would be (or rather should be) a restriction for which theme based icon bundle is available. However, due to the complex nature of CKE and font based icons, this module hasn't gotten very far.

I'm not suggesting that we remove the ability to use CSS/font based icons, rather add to the ability. There's already the concept of different renderers in Icon, I had planned on adding a 'File URL' one at some stage.

 

With all that said, the complexity of extracting the Icons may be enough to kill this issue along. In which case the alternatives for my specific use case would be to potentially categories bundles, so that Wysiwyg Fields could choose to show only physical file based Icon bundles.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Needs review » Postponed

I'm also not suggesting adding a dependency, if you look at the reference file it's just a very small snippet of code, I would be writing the code natively into Icon API.

Hmm. Well, even if we included this file, we'd first need them to license it as GPLv2 or MIT. Also, I'm not usually in the habit of just placing other people's code in my project unless there's no visual project (i.e. like I did with the array stuff from php.net comments). Typically, if it is code found on external sources like GitHub or BitBuck, I reference it as a required "library". If this issue does come through fruition and we end up needing it though, I would be OK with asking the author if we could just commit directly to this project... considering it is so small.

I think you misunderstand the use case. Wysiwyg Fields uses the Icon for a CKEditor native plugin, which does require a physical file.

Ah, yes, I definitely misunderstood. Yes, CKE requires a physical icon file for the item button in the toolbar. I was thinking more long term and having the ability for people to actually insert icons directly in their content via CKE/icon picker, but we can leave that for #1934250: Add CKEditor plugin to use with icon_filter sub-module.

In which case the alternatives for my specific use case would be to potentially categories bundles, so that Wysiwyg Fields could choose to show only physical file based Icon bundles.

So yes, I think the solution is adding an ability to "restrict" what kind of bundles you want to choose from the icon_selector (which is something I've had on my mind for a while actually). In the case of wysiwyg_fields the field formatter icon setting would need to restrict bundles to the "image" render type, maybe "svg" too?

I'm not sure if I should keep this open or not since #2370899: Show icon on icon_selector dropdown list is likely to completely re-architect the icon_selector element anyway. I'm tempted to say that we should address the "restriction" ability in that issue so it's being designed with that in mind (along with #1989234: Support icon variations).

I'd be fine with postponing the "restriction" feature and repurposing it to this issue though. Either way, postponing for now so you can weigh in.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented
Status: Postponed » Closed (won't fix)

Hmm. Well, even if we included this file, we'd first need them to license it as GPLv2 or MIT. Also, I'm not usually in the habit of just placing other people's code in my project unless there's no visual project (i.e. like I did with the array stuff from php.net comments). Typically, if it is code found on external sources like GitHub or BitBuck, I reference it as a required "library". If this issue does come through fruition and we end up needing it though, I would be OK with asking the author if we could just commit directly to this project... considering it is so small.

Again, not suggesting we use the code, there's literally only 5 or so lines of code that are even useful in that example, and even then, not very. It was more of a demonstration of how to work with font SVGs, I already played with that approach and it will be very difficult.

I'm not sure if I should keep this open or not since #2370899: Show icon on icon_selector dropdown list is likely to completely re-architect the icon_selector element anyway. I'm tempted to say that we should address the "restriction" ability in that issue so it's being designed with that in mind (along with #1989234: Support icon variations).

I agree, for the moment, extracting from fonts, as ideal as it sounds (to me) is a bigger task than worth while. For the purposes of exposing FontAwesome or Glyphicons, I believe there are already multiple repositories containing the extracted icons which could be used to make a new Icon bundle without the pain. While it would be annoying to have to have two Bootstrap bundles, it's probably the lesser of two evils.