Matt Keys

Okay that does make some sense if you were maybe upgrading from a site that used this plugin with FontAwesome 4.x icons. The concept of ‘active icon sets’ didn’t exist back then. I should still add a sanity check in the code here to make sure that there is an array before trying to use it. I’ll look to do that in the next release.

Hello, thanks for reporting the error. I wonder if you would be comfortable/able to log the value of $active_icon_sets in your environment. In that class-ACFFA-Loader-6.php file mentioned in the error above, right before line #201. You could do it like:

...
$search_custom_icon_set	= false;

file_put_contents($_SERVER['DOCUMENT_ROOT'] . '/log_active_icon_sets.txt', print_r($active_icon_sets, true));

if ( isset( $active_icon_sets ) // Make sure we have an icon set
...

Which would put a txt file called log_active_icon_sets.txt at the root of your site with the value of $active_icon_sets.

I’m very curious to see what is in this value that isn’t an array.

Thanks,

Matt Keys

Personally I wouldn’t rely on an editor to unselect an icon in the admin area if they want to use an image instead.

I would have a button group, or select, or radio field (whichever makes sense to you) that has the options available to your editor, such as:

Image
FontAwesome Icon

I would then conditionally show the correct field (image or icon) in the admin area depending on their selection.

And finally in your template before displaying the image or icon value, you should first check which field they chose (image or icon) and only display that value.

With all of that said, this plugin also does have an option to allow an empty icon field. When you create your icon field in ACF look for the ‘Allow Null?’ option. If it is True, there will be a little ‘x’ on the icon field allowing you to unselect any selected value.

I’ve added some extra sanity checking here. I still haven’t been able to reproduce this exact issue and I’m curious what the value of $select_value was in your case. But I did see some potentially quirky behavior if someone had downgraded to FontAwesome 5.x icons after savings some 6.x icons. Although in those cases I’d expect to see some JSON in the $select_value, not an array.

But either way, I check for arrays or json objects in this area now to avoid issues. Thanks for reporting.

Matt

This should be fixed in 4.0.9 just released, let me know if you run into other issues.

Matt

This should be fixed in 4.0.9 just released, let me know if you run into other issues.

Matt

Okay it is looking like the solution here is going to be a small edit to /advanced-custom-fields-font-awesome/assets/inc/class-ACFFA-Loader-6.php on line #646

Old code:

case 'custom':
	$default_family = 'kit';
	break;

New code:

case 'custom':
case 'fak':
	$default_family = 'kit';
	break;

This will go out in 4.0.9 but that probably won’t come out today, feel free to make this adjustment manually if you’d like, or you can just wait until 4.0.9 to update.

FontAwesome has moved to a “family + style” categorization of their icons to accommodate more icon variety. Supporting this new concept has made things a bit tricky in this plugin.

So the new way to express these custom upload icons would be: fa-kit fa-custom-icon-name

or if it is a duotone custom icon: fa-kit-duotone fa-custom-icon-name

It looks like this is working in the plugin with icons that are newly selected icons when v4.0.8 is installed. However the bug seems to be with prior selected custom icons. I’ll see what I can do to put in a fallback for these older icons.

If you have a small amount of icons and you want to use v4.0.8 now, you can unselect/save/reselect your custom icons and they should work. However if you have a large amount of custom icons in use you might want to just wait for v4.0.9.

Thanks I’ll take a look.

Okay I see the bug. /advanced-custom-fields-font-awesome/fields/acf-font-awesome-v6.php

Line #362 should be updated to:

$path_data_element .= '<path d="' . $icon_json->path . '" />';

This is part of the fallback for older/previously selected non-duotone type icons. The code currently erroneously has $path_data_element = instead of $path_data_element .= so it is overwriting the opening <svg> element.

I’ll fix this in 4.0.9, hoping to hear back from another user about a different issue and solve them both in the same release. Feel free to do this adjustment manually if you’d like to start using 4.0.8 now.

Thanks for that extra info, should help me reproduce the issue.

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?

Hey @gerbull001,

Sorry for the late reply this one slipped under my radar. If you still have an environment that could reproduce this issue, are you able to log the value of $select_value and report back?

There are many ways to do that and you can feel free to use whatever you are comfortable with. I often do something like this for a quick log of something:

file_put_contents($_SERVER['DOCUMENT_ROOT'] . '/log_select_value.txt', print_r($select_value, true), FILE_APPEND);

This would put a log_select_value.txt file in the root of your site structure with the value in it. Don’t forget to remove the log file when you are done!

Hey @mhennessie,

I did make a change to this area in 4.0.8. I used to ‘prepare’ the SVG myself in this plugin. However that was causing issues with custom duotone icons not getting the proper attributes for the duotone effect. So I looked back at the FontAwesome API and I saw that the API can send the prepared SVG element which I can use instead.

I haven’t been able to reproduce the issue you are seeing, and I am trying to sort out what might be causing it. My two current theories:

1. The SVG element from the FontAwesome API is invalid for some reason. If you can share one of the icons here for testing, I can add it to my kit and see if I get the same issue.
2. This is a problem when you already have an SVG in place from before 4.0.8, and then update to that version of the plugin. One way to test this might be to unselect the icon where it is used (select another), then go back to the original icon. This should cause the icon to resave it’s attributes in the post/page meta and perhaps get the proper SVG element along the way.

Let me know if you are able to help me debug this testing out the theories above!

Hi @rms-psychotherapy,

That other thread has a Javascript error that was causing issues, but it doesn’t seem related to the problem you are having.

In your case it looks like the token really isn’t valid. Can you double check you are getting the right token from you FontAwesome account? There are two spots and I could see how one could easily grab the wrong one.

Make sure you are copying from the “API Tokens” section, not the “Package Token” area right above it. Additionally make sure your API token has the ‘Read Kits data’ permission checked with a green checkmark.