• After the most recent update, brand icons, specifically linkedin, don’t seem to be working in the frontend although I can select them and they render ok in the gutenberg preview in the admin area. It does flash up for a moment before switching to the broken question mark in a circle.

    I’m adding the field to a repeater using the ACF API like this:

    acf_add_local_field([
    'key' => 'small_icon_list_icon',
    'label' => 'Icon',
    'name' => 'small_icon_list_icon',
    'type' => 'font-awesome',
    'parent' => 'small_list_items',
    ]);

    I did wonder if I need to specify the icon sets in the code like this:

        acf_add_local_field([
    'key' => 'small_icon_list_icon',
    'label' => 'Icon',
    'name' => 'small_icon_list_icon',
    'type' => 'font-awesome',
    'parent' => 'small_list_items',
    'icon_sets' => ['brands', 'duotone'],
    ]);

    But that seems to break things further.

    Thanks for your help and making a great plugin!

    The page I need help with: [log in to see the link]

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Author Matt Keys

    (@mattkeys)

    This isn’t a way I’ve ever attempted to use this field. I think I remember seeing in the past that you can export fields to PHP though. So perhaps it would make sense to create the field group the old fashioned way first to accomplish a few things.

    1. Make sure that things are working when you create the field group through the UI.
    2. If things are working after making the group through the UI, generate the PHP so you can see what code is produced to possibly correct any errors or omissions in your own code.

    Like I said I haven’t tried this personally so this is a bit uncharted territory. The fact that you said the icon flashes for a second and then goes away makes me feel like we are chasing down the wrong thing, and it is more of a conflict of which resources are loading on the front end.

    But doing some more testing as outlined above might help figure that out. Please share your results.

    Thread Starter timbarkerse

    (@timbarkerse)

    Hi Matt,

    You were right that the ACF settings were a red-herring. The code specifying the icon-sets did work – I’m not sure what went wrong when I tried it before. When I built the field in the UI and exported to PHP it was pretty much identical.

    I looked further at the HTML that gets output by the ACF field and it looks like this:

    <i class="fa-classic fa-brands fa-linkedin"></i>

    If I manually remove the fa-classic class it works correctly. So this is fairly easy to work around in my code. Curious if I’m doing something wrong to generate those classes or if it might be a bug in the plugin. Maybe fa-classic isn’t enabled in the kit that I’m using – I don’t have very easy access to the kit config unfortunately so I can’t check.

    Thanks for your help. My work-around is doing the trick so no immediate need for help.

    Plugin Author Matt Keys

    (@mattkeys)

    If you can share a URL to a page that was having this problem I’d be curious to look at it. The fa-classic class shouldn’t really do anything, so I’m curious to see why it does on your site.

    Thread Starter timbarkerse

    (@timbarkerse)

    The issue was here https://www.vqcomms.com/contact-us/ but of course I’ve fixed it now by removing fa-classic using PHP (and don’t want to break it again to demonstrate).

    If it’s useful, I am looking at my local version and when fa-classic is present it looks like the javascript swaps out the icon for a svg which doesn’t happen with the other icons. I’m loading FA myself so it could be the way I’m doing that or how my kit is configured. See the below screenshot from dev inspector.

    Plugin Author Matt Keys

    (@mattkeys)

    Thanks for the reply. Just to confirm, on your FontAwesome kit settings page. Do you have your kit technology set to “Web Fonts” or “SVG”?

    Even some of the icons that are working look funny/wrong to me. Such as this one in your source:

    <i class="fa-duotone fa-duotone fa-location-pin" aria-hidden="true"></i>

    That should look like this:

    <i class="fa-duotone fa-solid fa-location-pin" aria-hidden="true"></i>

    Note how yours says “fa-duotone” twice, and omits “fa-solid”?

    In your FontAwesome ACF settings, do you have the return value set to “Icon Element”? Or are you instead returning something like the Icon Object, and building your own HTML?

    I’ve been experiencing the same issue as @timbarkerse, where brand icons such as facebook, instagram, x-twitter and linkedin-in all have the class ‘fa-classic’ attached to them by the plug-in, which causes the Font Awesome script to swap in a ‘missing’ SVG rather than the intended icon. Icons from the other FA styles I’m using in the kit (solid and thin) do not do this and are working fine.

    The FA kit is set to technology: SVG, embed code: JS, version: 6.x. I am self-hosting the kit by installing it via npm and enqueuing the fontawesome.js and all.js scripts to handle the SVG insertion. The FontAwesome ACF field is set to return just the Icon Class which I am attaching to an i tag.

    To get around the issue, I have also implemented a similar fix to Tim by using a str_replace to manually remove ‘fa-classic’ from the classname returned by the plugin, that allows the script to insert the SVG just fine.

    For reference, the PHP code without the fix looks like this:

    <i class="<?php echo get_sub_field('icon'); ?> fa-2xl" alt="<?php the_sub_field('name'); ?>"></i>

    Which causes this outcome:

    The PHP fix I’ve written looks like this:

    <i class="<?php echo str_replace("fa-classic", "", get_sub_field('icon')); ?> fa-2xl" alt="<?php the_sub_field('name'); ?>"></i>

    And this leads to success:

    Plugin Author Matt Keys

    (@mattkeys)

    Hey @drlow1 thanks for adding your experiences here.

    I am having trouble repeating the issue on my end. I am not sure what would be different between our two environments. Is it possible that FontAwesome resources are being loaded twice on your frontend? Like manually but also by my plugin or another plugin you have installed?

    What happens if you just hardcode this in your theme somewhere. This should remove the ACF/my plugin from the equation to help narrow down what is going on here.

    <i class="fa-classic fa-brands fa-x-twitter fa-2xl" alt="twitter"></i>

    When I test with that code, the FontAwesome JS successfully turns it into the x-twitter icon. But your screenshots seem to suggest it would fail. Which doesn’t make much sense to me why we’d be getting different results.

    Please let me know what you see!

    Hi @mattkeys, thanks for the quick response! FontAwesome doesn’t appear to be getting getting enqueued multiple times, and adding that hardcoded i element still produced the missing SVG I was getting previously.

    However, I’ve continued to look into this issue this morning and I’ve found a possible culprit for what is stopping the brand icons from appearing. One thing I forgot to mention before is that my FA kit contains custom icons, and bizarrely I think that may have something to do with the issue.

    First of all, I found that brand icons with the fa-classic classname would have their SVGs appear correctly so long as I enqueued the brands.js, solid.js, thin.js and custom-icons.js scripts separately instead of just the all.js script. If I enqueued the all.js script in addition to the other 4 scripts, the brand icons would also break in that case.

    I had a hunch that the custom icons may have been causing some complications, and sure enough if I remove all custom icons from kit all.js can render the brand icons with the fa-classic classname just fine.

    I’m not sure if @timbarkerse also had custom icons in their kit? But overall, I’m wondering if the issue is with FA kits themselves rather than this plug-in. Rather than removing the fa-classic classname from brand icons a better solution for now may be that if a kit has custom icons, enqueue the scripts for the different FA styles separately. Why only the brand icons are affected by this, and why all icons seem to work together when the style scripts are enqueued separately, I’m at a loss for though.

    Plugin Author Matt Keys

    (@mattkeys)

    Hey @drlow1,

    Thanks for the extra digging. I’ve tried to reproduce the error, let me know if this sounds correct:

    • I have a FontAwesome KIT which includes custom uploaded icons. I downloaded those files for self hosting.
    • I added the all.js and fontawesome.js files to my test sites head.
    • I disabled all other calls to the fontawesome kit to ensure that my self hosted files were doing the job of loading the icons.
    • I hardcoded the same test icon as I shared with your before (the x-twitter one) in my theme template.

    When I load the site on the frontend, the icon displays as it should.

    I have a contact at FontAwesome I can report bugs to if this is something I can figure out how to reproduce. Let me know if there is something wrong in my test. Also maybe worth seeing if you can reproduce it in a different site or ‘vanilla’ WordPress environment. Perhaps there is something else conflicting here?

Viewing 9 replies - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.