Matt Keys

I suppose the current behavior would be to hide the admin page completely if that hook is in use though wouldn’t it?

Yes I see the issue.

You are passing the third optional argument to get_field():

get_field($acf_field['key'], $root->ID, false)

That third argument is called format_value. By passing false to that argument you are telling it to give you the raw result from the DB without any formatting.

Removing that argument or changing it to true should resolve things for you.

Hello, I do recognize what is going on here but I am unsure *where* the fix is.

When you change the “Return Value” settings in an ACF field you are telling ACF how you want the value back. And so long as you use ACF functions to retrieve that value like get_field() or get_sub_field(), you will get the specified return value format.

But if you get the value another way, you are bypassing that ACF functionality and you will instead get the raw value from the database. I’ve seen this happen with other users of my plugin who are using get_post_meta() to retrieve their values.

The fact that it used to work in your implementation with FontAwesome 5.x icons is actually a coincidence. You are looking for just the plain icon class, and that is how 5.x icons are stored in the database. So the raw DB value that was being returned happened to match what you needed/wanted. FontAwesome 6.x icons are a lot more complex and I’ve had to store more data in the database which is why that is no longer the case.

I am not a WP GraphQL user so I’m not familiar with how that plugin handles value formatting. Many of the ACF ‘core’ field types also have different return value options that I am guessing WP GraphQL already handles properly. It is likely that because my field is a third party field type it just has not been considered. Maybe they do not consider 3rd party fields as a matter of policy. Which would leave either a filter function that would go in your functions.php, or perhaps for future inclusion in my plugin.

Skimming the docs here: https://acf.wpgraphql.com/ I see this in their FAQ

• I have an ACF Extension that adds a new field type, will it work with WPGraphQL for ACF?WPGraphQL for ACF supports the field types that come with ACF (Free and PRO) as well as the field typs in ACF Extended (Free and PRO). Support for additional field types can be added by using the “register_graphql_acf_field_type” API.

If this is something you experiment with, please share your results here. If WPGraphQL doesn’t want to support this field type natively perhaps this plugin could register itself.

Sorry for the late reply! Thank you for sharing the error code that is helpful. This looks like it has nothing to do with Avada theme.

A couple questions:

1) Can you ensure you are on the latest version of this plugin? The error message you shared mentioned json_decode() on line number 212. However in the latest version of this plugin that code gets executed on line 219. Let me know if the problem persists on the latest version.

2) Were you previously using a much older version of this plugin, and have recently updated it and then started running into this problem?

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?

Hello @bytefight,

Sorry you are running into issues. You mentioned a critical error, do you mean a PHP or a JS error? Are you able to reply with the error message?

That would help narrow down what is going on here.

Avada is a very popular theme so you are probably not the only one trying to use this plugin with it. This is the first error I recall related to it though (if it is even the cause).

Matt Keys

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!

thanks ??

You could check the PHP error log on your server to see if something were happening there.

I wonder if you have another environment, such as a local environment or a website hosted on another server not on Hostgator that you could do some additional testing on? You can add the URLs as ‘custom’ URLs so you are checking the same URL as the sites you are seeing this issue on.

Also worth checking is if your API key has any restrictions enabled that may be preventing it from being used on the sites you are trying it on. If you are able to test on another environment it should help narrow down if this is a Hostgator issue, or an issue occurring somewhere else.

Hi @chintansatva,

Do you ever see the progress bar at the top of the screen showing that “Google Pagespeed is running in the background”?

I am not aware of any widespread compatibility issues with this plugin that can be fixed on my end. It is possible that hostgator is enforcing a strict maximum amount of time that any single task is allowed to run for on your server. This can be especially likely with very low cost hosting providers as they try to conserve limited resources. There is a “Maximum Script Run Time” option in the advanced configuration of the plugin that you can try testing with to see if there is a value that allows the scan to finish without being killed by the server. I’d maybe start around 60 seconds and lower it from there.

Hey @dirkvw001,

Thanks again for the bug report, that issue with the icon sets should be fixed in v4.1.1 which I just released.

As for the ACF fields in your menus. While the json_decode workaround you are using will also work, there is nothing to say it will continue working in future releases of this plugin. The safe route is to use the proper ACF functions for retrieving values from your fields. You can read the docs here: https://www.advancedcustomfields.com/resources/adding-fields-menu-items/

I’d expect your code for getting the icon value to end up looking something like:

$icon_class = get_field( 'menu_icon', $item );

As for why this *used* to work for you but no longer does. In prior versions of this plugin, the class was stored in the database how you happened to need it. In current versions there is instead a JSON object as I needed to store more information in the database. Using the ACF functions will make any future changes to this not effect you.

Thanks for reporting. I’ll take a look at item #1, this last update did include a code change in that area that must be related.

As for the second item, can you confirm you are using the ACF “get_field” / “get_sub_field” functions to get your value? The symptoms you report sounds like you might be using the WordPress “get_post_meta” function which would bypass the field formatting and return the raw JSON from the database.

Matt Keys

Looking at this a bit further today, it actually isn’t really the place of this plugin to change this CSS.

The change should happen in your theme. There are two points you could chose to fix this. The button.btn element in your theme is getting this CSS giving it a font weight of 600. This would break the icons.

button.btn {
    font:600 16px/18px Museo Sans,sans-serif;
}

However elsewhere in your CSS you have this rule:

i.fak {
    font-weight:400!important
}

This overrides the font weight 600 applied earlier. However as you noticed this fix is no longer working in the latest version of this plugin, because the .fak class no longer targets the icon with the new Family + Style format of Font Awesome.

So you could either avoid giving a font weight of 600 to this area in the first place. Or you could update your fix to target the new CSS selector for the icon.

I hope this helps.

FYI this will be fixed in the next release, in the meantime feel free to add font-weight: 400 !important as a workaround or just stick with 4.0.6 until the next release.

I can’t see the staging server due to user/pass requirement. However from your description I think you are right on the money about the CSS being at issue. I’ll take a look at that.