Matt Keys

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.

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.

Hey @precies,

When configuring your ACF FA field, if you have it set to enqueue FontAwesome, it will only do so when a field is being used. The thinking there was to prevent loading resources when they aren’t needed.

However for people in your situation there is a filter that will tell this plugin to always enqueue regardless if a field is on the page. “ACFFA_always_enqueue_fa“

This could be used in your functions.php like below:

add_filter( 'ACFFA_always_enqueue_fa', '__return_true' );

Another alternative would be to set it to not enqueue fontawesome in the ACF field settings, and handle that yourself on the frontend. If you are using a kit, just make sure and load the same kit as you are using in the backend.

Whatever you do just make sure only one instance of FontAwesome is being loaded the page at a time to avoid conflicts.

Thanks for testing!

Okay so I looked at this some more today. I am manually building an SVG element from the SVG paths. And things are getting complicated now that I added duotone support in this area and there could be multiple paths.

Looking back at the FontAwesome API, I am making things harder on myself than I need to. They have a prepared SVG html element that can be returned from the API so I don’t have to build it myself.

I’ve added functionality to use this going forward, but already selected custom icons won’t be able to use it until they are reselected. So I also bug fixed the underlying issue with how I was building those SVGs manually and kept it as a fallback.

The new version is not out yet, can you do some testing on it to validate that it fixes the issue you were seeing and doesn’t cause any new problems for you?

You can get it here:

https://www.ads-software.com/plugins/advanced-custom-fields-font-awesome/advanced/

Under ‘Advanced Options’ look for version 4.0.8

Thanks, let me know how it goes!

Okay I see it now. That is definitely a new one. This plugin isn’t doing anything too clever to get the number of posts there.

It uses the WordPress core function “wp_count_posts”, and shows the total number of published posts for each of the post types. Are you sure that your pages are published and not in a draft/private/other status?

That image seems to be broken, are you able to share it another way?

Thanks for the example SVG. I am able to reproduce the error but I’m not sure of the cause yet.

Earlier versions of this plugin got the SVG path from the GraphQL “path” field of an iconUpload object. However “path” was deprecated in favor of pathData, which is similar to path but it can have more than one path to support things like duotone icons.

The error you are seeing sounds related to this, it is trying to output the value of path, but the value of path seems to be an array.

How the new version of this plugin handles this, is that it json_encode’s those arrays.

I suspect if you were to unselect the icon > save your page > then reselect the icon >and save again: the problem would go away.

Are you able to confirm?

Glad it was something easy!

Enjoy.

So I have tested custom icons with this release, although not generated through the icon wizard like the one you are trying to use.

This plugin doesn’t do very much on the frontend other than output the element and enqueue FontAwesome (if enabled).

My first thought is whether or not the correct FontAwesome KIT is being loaded on the frontend? The one that includes this custom icon.

Also I see you are using SVGs on the frontend, Does it work on the frontend if you display it using the <i> element?

• This reply was modified 9 months, 3 weeks ago by Matt Keys.

Ah, yeah I was wondering if maybe you were doing some string manipulation on the icon element. I think for your use case you are on the right track with setting your field to return the ‘object’ instead.

FontAwesome has evolved to a number of ‘families’: Classic, Sharp, and Brands. fa-classic, fa-sharp, fa-brands. It seems possible, maybe even likely that there will be more families to come in the future.

This plugin has been refactored in this latest release to support this new concept of families. Having fa-classic in the class is not strictly required, but in consultation with FontAwesome on the topic we agreed that being a little verbose when generating these shouldn’t harm anything.

I am curious to hear more about your use case where having this class in the icon is breaking things.

Some more info on the concept of families here: https://docs.fontawesome.com/web/dig-deeper/styles

• This reply was modified 9 months, 4 weeks ago by Matt Keys.

I’ve launched 4.0.7 today.

I looked into standardizing those filters. It seems almost everywhere else I made uppercase ACFFA_ the norm. The “lowercased filters” you found are sort of undocumented functionality already out in the wild. I thought about changing them to be uppercase, but I’ve decided against it as I don’t want to mess up anyones code referencing the lowercase version.

So it will just be a little quirk in the code. I’ll try and stick to uppercase going forward.

Just an FYI, I have been chatting with FontAwesome about this. I don’t have an ETA but it is something that is being thought about/is on the road map.