Setting Enqueue To No & Enqueuing A Locally Hosted All.css instead?

Yes the plugin just enqueues the all.css file you mentioned. If you aren’t letting the plugin do that, and things aren’t working, I would double check the you have the correct version of FontAwesome enqueued to match the icons you are using. Additionally I’d double check that you have all of the correct prefix classes needed on your icons for the font to successfully show up.

Hi Matt,

I’ve just tried the following two methods:

1.) I copy and pasted the very css contents of the file that your plugin links to. When your plugin links externally – the css contents of all.css spring into action. When I host the exact same file locally – I don’t get icons.

I am placing this code in the footer of my website:

<link rel='stylesheet' id='font-awesome-css' href='https://mywebsite.com/staging/wp-content/external/all.css' type='text/css' media='all' />

2.) Operating on your suggestion that I needed to load different font awesome css. I used the same method above to load all of the individual css files from font awesome (brands, font-awesome, regular, solid, etc.) Still didn’t work for me.

I have all caching off.

I’ve tried placed the stylesheet links in footer, header, and body. Still no luck on my end.

Is something wrong with my code above?

assuming that is a valid URL, the link tag looks correct. I can’t explain why the icons only load when my plugin loads that CSS for your compared to loading it yourself. Sounds like something quirky going on that is specific to your environment and may take some trial/error to debug.

The first quirky idea that popped in my mind, is that you have some other plugin or theme also loading an older copy of the fontawesome CSS. And by chance my plugin loads its fontawesome CSS *after* that other plugin, and therefor takes priority. Whereas when you load it yourself it is happening *before* this other copy of the CSS and is being overridden. Hard to say if that is happening to you or not, but I suspect you are dealing with some kind of quirky edge case like that.

Hi Matt,

Great insights, but still no success. Could your plugin be domain specific in terms of requiring font-awesome to come from ‘use.font-awesome.com’?

Here is what I have observed:

I followed your intuition in which you stated the placement of the <link> code could be the culprit.

I used view source to copy the exact link code that your plugin generates:
<link rel='stylesheet' id='font-awesome-css' href='https://use.fontawesome.com/releases/v5.13.0/css/all.css?ver=5.3.3' type='text/css' media='all' />

I turned off your plugin’s enqueue functionality for each of my icons.

I manually inserted the <link> code in different places in my page structure (header, body, footer). Each instance loaded the fonts perfectly.

It is only when I do not use the ‘use.fontawesome.com’ file that my issue arrises.

When I use my own file I copy and paste the exact contents of:
https://use.fontawesome.com/releases/v5.13.0/css/all.css?ver=5.3.3 into a new locally hosted css file.

I then confirm a successful ‘200’ message using DevTools.

This has me stumped.

Are there any other factors aside from placement that you can think of?

My setup is as follows:
I have ACF icons on a page.
Each icon has ‘enqueuing’ set to off.
I load a local exact copy of the font-awesome all.css file.
I check for a successful ‘200’ message that the local css file is loaded.
Positioning doesn’t seem to be the problem.

Could your plugin only be accepting all.css from a specific domain (use.font-awesome, in this case) and be ignoring all other possible sources for all.css?

Hey, sorry you are still having issues debugging this.

Could your plugin only be accepting all.css from a specific domain (use.font-awesome, in this case) and be ignoring all other possible sources for all.css?

There is no such code in my plugin. It actually does very little on the frontend:

• Optionally outputs the FontAwesome CSS file (which you have off)
• Renders/outputs the FontAwesome field according to your settings, and where you use the_field/get_field/etc in your template.

Everything else from that point forward is out of my plugin’s hands.

If you are familiar with the browser inspector, looking at some of your icons and comparing the CSS the inspector is showing applied to those icons, first with the use.fontawesome.com css, then with your own.

Another approach would be to ignore my plugin for now, and see if you can just get a FontAwesome icon to load correctly following the guides from FontAwesome’s documentation.

https://fontawesome.com/how-to-use/on-the-web/referencing-icons/basic-use

Whatever you do here to make icons show on the frontend should also be compatible when you start displaying fields with my plugin.