The Font Awesome v5 WordPress Problem

This blog post is mainly to draw attention to the brewing problem with using Font Awesome v5 in your WordPress Plugin or Theme.

What is Font Awesome?

It’s a little CSS (or JS in v5) file that you can add to your site to be able to use lots and lots of fancy icons on your site.

What’s the problem?

There are really two problems;

1. The first (less serious) problem is a common problem with JS/CSS libraries and WordPress and can affect FA v4 not just FA v5, that is the fact that two developers might add the script and use different names so the same file gets added to the website twice. The fix to this is relatively simple and is resolved by the two devs using the same name to add the file, we use and we suggest “font-awesome”.

2. The main brewing problem with using Font Awesome in WP these days is that FA v5 introduced a new way to use it, in FA v4 it was always just a CSS file but now it can be used either as a CSS file or as a JS file. This is fine for “Joe Blogs” with his html website but once you are using a CMS (content management system) like WordPress which has plugins built by many many devs you have the situation that both the CSS and the JS can be used and this can lead to many problems.

The main problem is

that the JS version of FA will replace the item that has the FA class with a

<svg>

tag, this is not by its self a problem but the problem is when developers have been using just the CSS version and either style for that tag or use JS to fire a onclick method on that specific tag or even on a link or button which in all cases your going to have a bad time.

Just today i seen issues with two widely used WP products, the first was with Ninja Forms, they use the FA v5 CSS version and if the JS version of FA is loaded then you can’t exit out of the form edit screen as their

<a>

tag link to exit is rendered as a

<svg>

tag and is no longer a link. The other issue i seen this with was the BuddyBoss theme, they do something similar with an

<a>

tag but its href=”#” so that is not the problem but the onclick handler i guess targets the

<a>

tag and so again it does not fire.

The solution

1. Developers, please name your scripts “font-awesome” when you enqueue them.
(i know you might run into version issues but its likely far less of an issue than if you load it twice).

2. The main problem:
Devs have been used to being able to use the FA classes anywhere like on links and buttons but to make it all nice an compatible for everyone we should all just stick to the recommended way of using

<i>

tags.
The beauty of this fix is that it is pretty simple, it would change something like:

<a href="#" id="custom-nav" class="sidebar-btn fa fa-bars"></a>

to:

<a href="#" id="custom-nav" class="sidebar-btn">
<i class="fas fa-bars"></i>
</a>

After thoughts

I think a simple plugin that dequeued all the added FA CSS/JS and then added the latest JS FA might be handy but it would still be affected with the main problem here unless we make it an industry standard to always use the

<i>

tags…