Some custom icons not displaying correctly
-
I’m having an issue but just with SOME of our custom icons which seems extra hard to troubleshoot. They are all being pulled in the same way and all part of the same kit. I reached out to Font Awesome support who said that the issue is because, “there is an extra class on there “fa-custom” that is messing things up” and to remove it. However some of the icons with the class still displayed and eventually we figured out it was because, “We were able to figure out the root issue with your custom icons. Any class that starts with “fa-” is interpreted by our javascript as something it should pay attention to, so generally you should avoid adding classes that start with “fa-” to your html. As for the change in behavior, in our Version 6.7.0 release we adjusted how our script looks at the classes it finds on an html element. It now sorts the classes in alphabetical order before processing (to be able to handle some of our newer Duotone icons) which changed the behavior of a class like “fa-custom”. Before the release, if an unknown class starting with “fa-” came before the icon name (like “fa-coffee-table”) the icon would work but not if it came after. Now, if the icon name comes alphabetically before the unknown class name, it won’t work. So “fa-coffee-table” comes alphabetically before “fa-custom” which results in a missing icon – but a name like “fa-drapes” comes alphabetically after “fa-custom” so it will work, which explains why only some of your custom icons were having issues. Long story short, they best fix is to remove the “fa-custom” class or rename it to “custom-icon” – anything without “fa-” at the beginning.”
However because the class is coming from the ACF:fontawesome plugin I can’t adjust it. While working with FontAwesome they said, “We were able to connect with Matt, the developer of Advanced Custom Fields: Font Awesome, and he confirmed that that the extra “fa-custom” class is coming from the plugin. He suggested that you could change the “Return Value” to “Icon Object” instead of “Icon Element” to control the code that the plugin outputs so you can remove the “fa-custom” class.”
I have switched the “Return Value” to “Icon Object” and am continuing to have the same issue. Is there something else I need to do to solve this?
-
Hey thanks for reaching out, I do remember this conversation with the FontAwesome team. I believe a fix is coming in a future release that will basically tell the JS to ignore the ‘fa-custom’ family class when rendering. But they stated it will only help ‘going forward’ and it sounds like that might only be for FontAwesome 7.
I did mention a possible workaround to them which it sounds like you’ve looked at a little. Currently if you have the icon set to return the “Icon Element” you would get something like this:
<i class="fa-kit fa-custom fa-drapes" aria-hidden="true"></i>Changing the output to “Icon Object” would change what is returned to something like this:
stdClass Object
(
[element] => <i class="fa-kit fa-custom fa-drapes" aria-hidden="true"></i>
[class] => fa-kit fa-custom fa-drapes
[id] => drapes
[family] => kit
[style] => custom
[prefix] => fa-kit fa-custom
[hex] => \57346
[unicode] =>
[svg] => stdClass Object
(
[SVG data here I am going to ignore for this example]
)
)Using the data in this object, you can build your own icon element to look however you need/want it to. You could do something like:
$icon_object = get_field( 'my_fa_icon' );
$icon_family = isset( $icon_object->family ) ? 'fa-' . $icon_object->family : '';
$icon_id = isset( $icon_object->id ) ? 'fa-' . $icon_object->id : '';
$icon = "<i class='" . $icon_family . " " . $icon_id . "' aria-hidden='true'></i>";In this example, if you were to echo $icon you would get:
<i class="fa-kit fa-drapes" aria-hidden="true"></i>It is worth mentioning why fa-custom is there to begin with. “Custom” is the styleName within the FontAwesome nomenclature for these custom uploaded icons. My plugin always outputs the Family (fa-kit), Style (fa-custom), and ID (fa-drapes) classes when generating an icon. I believe this is correct, but it seems in this case it was not considered in the FontAwesome JS renderer.
It is possible in a future update to this plugin I may break this standard if enough people are running into this issue and it isn’t something that FontAwesome can correct on their end. Currently you are the only one I’ve heard from on this (lucky you). If I change this to remove the fa-custom class I run the potential of causing more issues by removing a class that other users may be targeting in their CSS/JS. So I plan to let this play out for a little bit and see what kind of feedback I get from users, or what changes come down the line from the FontAwesome team.
Let me know if you have any issues with that workaround I gave you though and I’d be happy to help. Sorry you’ve been dealing with all of this!
You must be logged in to reply to this topic.
