mlwilkerson

@kowimedia I’m not able to reproduce a problem with version 4 compatibility with rc9. All of my tests that exercise v4 compatibility scenarios are passing. It might be the case that your situation represents a different scenario that I have not anticipated. In which case, I’d like to be able to create a test case to exercise it. But I need more information from you about your scenario in order to do that.

Here’s a visual demonstration that v4 compatibility works in rc9 using the example plugin that’s in our plugin’s code base. The plugin is called “Gamma”, and it references the bathtub icon using a version 4 class name, and loads its own version of FA 4.7.0 from a CDN. It also puts in some version 4 icons using CSS pseudo-elements, hard-coding the version 4 font-family name with unicode content. These are the common cases where I’ve previously observed problems with v4 compatibility.

Here’s the BEFORE snapshot, Gamma doing its thing without this Font Awesome plugin enabled:
https://www.evernote.com/l/AAfcMgCInfZLYoH0HbVwngmRZoWkkfZTMOs

And here’s the AFTER snapshot, showing v4 compatibility working:
https://www.evernote.com/l/AAetwZYoHKFIOKPFH_b7y7a0F8e-pW6bnNg

To produce these screenshots I installed this plugin, version rc9, directly from the WordPress plugins directory from within a clean installation of WordPress.

I’ll resolve this topic for now, but will gladly re-open if you can help me to reproduce the error.

Hi @jakrenegade. That page you linked isn’t loading for me. But when looking at the source code for sociochaux.fr it looks like the Font Awesome plugin is loading the webfont method successfully, with the v4 shims, and I can see the twitter and facebook icons at the top.

If you could provide screen shots of the page that isn’t working, along with screenshots of your plugin configuration settings, that might help me to better identify the problem.

Normally in a situation like yours, in addition to enabling v4 compatibility, you’d also need to enable the “Remove unregistered clients” option. This causes this plugin to attempt to remove those conflicting versions you’ve seen. It doesn’t work always, because it depends on the way the theme or other plugins are trying to load their own versions of Font Awesome. But does work most of the time, since plugins normally try to load Font Awesome in a standard way.

Hi @kdric. Your question about lists has less to do with this plugin, and more to do with how Font Awesome works with CSS more generally. A wizard on my team who knows the CSS far better than me worked up this CodePen demo that can shed some light on your situation:
https://codepen.io/fontawesome/pen/VNJzjz

Another possibility you might consider: if you want both to be able to self-host icon assets and use a shortcode, would be to just add code to support both to your functions.php.

You could use the code that supports shortcodes in this plug as a guideline:
https://github.com/FortAwesome/wordpress-fontawesome/blob/537a110f4fd1152d588a0f40528aba147447dd6e/includes/class-fontawesome.php#L1755

Most of the code in that function is actually for dealing with mapping v3 icon names. If you’re not trying to do that, then implementation of the shortcode could be very brief–just a few lines of code.

Wonderful!

Hello, @naner14. Sorry to have let so much time pass on this one. Not sure what you think about how the site is doing now, but I just had another look (the link you posted above). I can see that here are multiple versions of Font Awesome being loaded: one by your theme, and at least one other by a plugin. This includes both Font Awesome 4 and 5. So I wouldn’t be surprised if you see some strange behavior. Our plugin tries to resolve such compatibility issues, but it can’t always do it 100% right, since it involves some estimation as to how those other plugins or theme are loading Font Awesome. Your testimonials plugin, for example, seems to be adding some additional custom CSS that our plugin won’t be able to fix if you found that it was causing problems.

Regardless of all that, as far as I can tell at a glance, it looks like all of the icons may be showing up as you expect. Is that so?

-mike

Thanks for the report Damian. I’d need some more information in order to troubleshoot that one. Initially, I’d like to see what is reported in the JavaScript and Network consoles of your browser.

I saw an issue with another user recently where the web hosting provider had not been allowing certain kinds of web requests on the web server. I wondering if that’s happening here as well.

Hi Lars,

Thanks for the report.

You can download the rc7 release from the plugins directory page advanced view. Scroll the bottom and select a previous version to download. You’d then use that zip file to do an upload install of the plugin in WordPress.

However, I would like to better understand what’s going on here in rc9, so I can fix it. Do you have a site you could link me to where this problem is currently happening?

-mike

It looks like your theme is trying to load its own, conflicting version of Font Awesome, in addition to the one you’re loading with this plugin. That’s probably the cause of the problem.

You could try to enable the option on the Font Awesome plugin options page: “Remove unregistered clients”. Ideally, that will just stop your theme from trying to load the conflicting version, but the version you load instead would still be compatible with the theme.

Can you give that a try and let me know if it works?

OK, thanks for that confirmation.

Yes, unfortunately, the performance problems are pretty much unavoidable if using SVG/JS and pseudo-elements. We know that sometimes you must use them, especially if you’re adding icons to html elements for which you don’t control the markup. In those cases, it’s usually best for performance to use the webfont method if you can’t eliminate the pseudo-elements.

There is a lower-level advanced option for limiting the scope within the DOM in which icon markup and pseudo-elements are searched and replaced with SVGs.

You could add a <script> that appears after the <script> that loads Font Awesome, which could make a call to dom.watch() and pass parameters that limit the scope of the DOM being watched. If you know for sure that you only want a limited scope to be watched, you could narrow it this way, which would improve performance.
https://fontawesome.com/how-to-use/with-the-api/methods/dom-watch

You might also use such a script to configure Font Awesome to disable pseudo-elements only while in admin (but let them work as normal on public facing pages), or to turn off auto replacement altogether while in the admin UI.
https://fontawesome.com/how-to-use/with-the-api/setup/configuration

These lower-level tweaks might have unintended side-effects with other plugins that are trying to use Font Awesome, so it’s not a good solution unless you’re sure about your approach. Also, it’s not supported by this plugin, so you’d need to add a hook to your functions.php, for example, to add such extra <script> blocks.

I’ve just released version 4.0.0-rc8. Could you try that new version in your scenario and see if it makes a difference?

I’ve just released version 4.0.0-rc8. Since it eliminates a class of potential problems with compatibility with other WordPress plugins, it _might_ make a difference in this case. Could you give that new version a try?

If the slowness is happening while doing the actual post editing (the typing of the content and navigation around the editor in the browser), then the main way I can think of that there _might_ be some performance implications as a result of Font Awesome, would be if you have both the SVG method enabled for Font Awesome _and_ pseudo-elements support. There are some known performance problems with that in some situations, so we advise against using that configuration unless absolutely necessary. In generally, we advise against use pseudo-elements, when possible, to reference icons–in part for this reason. You could switch to the “webfont” method on the plugin’s options page to see if that makes a difference, since there’s no performance problem with pseudo-elements and webfonts.

I’m also curious if, when you have this combination of plugins installed, do you see any of the other ones show up as “unregistered clients” on the Font Awesome options page? If so, what happens when you enable that “Remove unregistered clients” option on the options page?

Finally, I just released version 4.0.0-rc8. It primarily addresses a class of potential conflicts with other plugins on the _back end_ (on the WordPress server, not in the admin UI in the browser), so I’m not sure how that would pertain to the issue you’re seeing with slow post editing on the front end. But since it does potentially impact interaction with other plugins, it might make a difference. Could you give 4.0.0-rc8 a try?

Hi @gbell12, thanks again for reporting this. I’ve just released version 4.0.0-rc8 that solves this problem by eliminating this whole class of potential conflicts with other plugins.

Could you give it another try?

Update: after looking at this more closely, we’ve concluded that we’d like to take greater measures to avoid conflicts like this now and in the future. I’m working on a set of changes that I hope to release soon.