Problem/Motivation

Font Awesome documentation says we can opt to specify styles (solid, brands, regular, etc). This is especially useful to us because we can use it to limit which icons we support.

Font Awesome Icons offers the option of choosing which partial file configurations will be used to limit the icons loaded.

Font Awesome Iconpicker does not limit the available icons based on the selected styles.

Steps to reproduce

  1. Follow this module's instructions to enable, add a text field, and configure the widget.
  2. Go to Configuration > Content authoring > Font Awesome Settings and limit to just the Solid (Free) style.
  3. Create or Edit a node with this field, and activate the icon picker modal.

You will still see Brand icons in the list.

Proposed resolution

Font Awesome Iconpicker says it fully supports integration with Font Awesome Icons. The configuration noted above limits the icons loaded into the system. Font Awesome Iconpicker should respect that configured limit.

Comments

jcandan created an issue. See original summary.

jcandan’s picture

jcandan commented

So far as I can see on a cursory review, the set of Icons determined to be available are hard-coded here and here (Not sure why it is listed twice, and each list is different).

I imagine we could refactor this to a single place. Then ensure that place gets the list from configuration. There may also probably need to be a mapping from the above configuration to the iconSource options listed at the vanila-icon-picker NPM package docs.

d34dman’s picture

d34dman commented
Assigned: Unassigned » d34dman
Priority: Normal » Major
d34dman’s picture

d34dman commented
Version: 3.0.0-rc1 » 3.x-dev

Oh dear, this one is quite tricky to resolve without introducing a breaking change.

The defaults in the JavaScript file will likely need to remain as they are
The list option in the JavaScript is currently used as a fallback when no configuration is provided from the Drupal side. I realize this might not have been the best design choice on my part, but changing it now would unfortunately cause a breaking change. So for the time being, it's safer to leave it as is.

The use case is further complicated by the lack of a hard dependency on Font Awesome

Because this module doesn't strictly depend on the Drupal Font Awesome module, I'm left unsure how to properly handle certain scenarios:

  1. Case A: A site builder uninstalls Font Awesome and switches to a custom implementation.
  2. Case B: A site builder installs Font Awesome but disables another icon library that was already in use.

To ensure proper compatibility with Font Awesome in such cases, I would effectively need to introduce a breaking change in how this module behaves.

So (takes a deep breath), to be more precise, the claim that fontawesome_iconpicker is compatible with other modules really ought to be revised to set clearer expectations. In reality, the only compatibility it has ever offered is that icons selected through fontawesome_iconpicker can still be rendered by any library made available through other modules.