mlwilkerson

The next major release of this plugin addresses this concern. It can be previewed here in our GitHub repo. The release notes on the initial alpha release describe the changes and provide some visuals.

Hi @lotgrafix. By WPMU, do you mean “multi user” or WordPress Multi-site?

If so, this Form Topic contains some important information about how to address the most common remaining problem with multi-site, now that this plugin supports it. Specifically, if you ever tried to install this plugin in a multi-site environment before it truly supported multi-site, then there are some extra clean up steps you must perform before it can work correctly.

The 4.4.0 version of this plugin did not yet support the Site Editor.

Version 4.5.0 was released yesterday and it does support the Site Editor. Give it a try!

@barcode20 there’s not enough information in your question for me to understand the issue.

It sounds like you might be saying that your web page as a <link> element whose href points to stylesheet that tries to load a webfont from the URL you provided, and that webfont is not available at that URL.

If so, then using this plugin wouldn’t eliminate that problem.

Unless it happens that there’s a theme or plugin loading that stylesheet, which this plugin’s Conflict Detection Scanner could detect, and block. That would stop it from trying to load that asset. It would load Font Awesome a clean way instead. See my comments over here on this other topic about how to use the Conflict Detection Scanner like that.

Hi @andreslav. I may only partially understand the problem you encountered.

However, it sounds like you’re saying that the Storefront theme loads its own version of Font Awesome which conflicts with the version of Font Awesome loaded by this plugin.

If so, and you want to try and use both together, then what might work is:

1. Use this plugin’s Conflict Detection Scanner from the Troubleshoot tab
2. Run the scanner on a Storefront page (where it loads its own version of Font Awesome)
3. See if the Conflict Detection Scanner detects it
4. If so, then go back to this plugin’s Troubleshoot tab. If it looks like what’s being loaded by Storefront is simply another version of Font Awesome, then you could select to “Block” it from being loaded.
5. If Storefront had been loading an older version of Font Awesome, then you may also need to “Enable Older Version Compatibility” on the Settings page of the plugin.

Caveat: sometimes, a theme like Storefront will include the Font Awesome CSS within it’s own theme CSS. In that case, you probably can’t block it without breaking the styling of theme. Thus, there would be no viable way to resolve the conflict.

In many cases, this will eliminate the conflicting load of Font Awesome being done by another theme or plugin. It won’t break their icons, because they will automagically use the icons loaded by your preferred version of Font Awesome, loaded by this plugin.

The “x-twitter” icon was added in Font Awesome 6.4.2. You can see it here in our Icon Gallery.

Because it’s in the Brands style, it’s part of Font Awesome Free.

Thanks. I’ve opened a GitHub issue for that here.

@modepc It sounds like this might be related to Web Application Firewall rules. If so, then it would make sense that using a different hosting provider has different results, because those security rules would be something set by the hosting environment.

I’ve just released plugin version 4.5.0 which changes how requests to the WordPress REST API are made, so that it better accommodates typical Web Application Firewall configurations. You might give it a shot.

However, depending on the “Booked” plugin integrations with ours (I don’t know) it may or may not automatically use a newer version of our plugin when available. But you could give it a shot.

1. install and activate the latest version of our plugin
2. try your scenario again and see if it works

@akanale When you refer to the WordPress Customizer, do you mean the thing that comes up when selecting Appearance -> Editor from the side nav?

If so, I just tried that with the latest version of this plugin (4.5.0) on WordPress 6.5.4 and it looks as expected (no blank page).

Could you try again with the latest version of this plugin? And if you continue to see the problem, please note specific details about how you’re accessing Customizer.

I’ve just released the plugin version 4.5.0, which is tested up to WordPress 6.5.4.

I was not able to reproduce this.

Running a clean install of WordPress 6.3.2 with only this plugin installed and active (version 4.4.0), I added a new photo to the media library. I then created a new post that included both that photo, selecting it from the media library, and an icon. Both rendered as expected on the front end page.

All versions of Font Awesome 6 Free are already loadable by this plugin.

If you’re on the “Use CDN” tab on the plugin’s settings, you can drop down the version selector and select whatever version you like.

If you are in “Use A Kit” mode, then it will use whatever kit you have selected. You control the version of Font Awesome used by that kit on the Kit Settings page for that kit in your fontawesome.com account. Again, you’ll be able to choose whatever version you want.

I’ve also looked at each of those vulnerabilities and confirmed that they pertain to other plugins. They are not vulnerabilities in this plugin’s latest version.

An earlier version of this plugin did have a vulnerability, and that was fixed in version 4.3.2, about a year ago.

Hi @albeaumont. If this is still a problem…make sure that litespeed cache is allowing PUT and POST requests to pass through the REST API routes on your WordPress site. To work properly, this plugin requires that the REST API is available.

Another user had a similar problem and found that some other software was binding a keyboard shortcut that caused the modal to close when keying particular characters. It may have been another WordPress plugin. I’d suggest considering what other plugins you have enabled that may have keyboard shortcuts enabled.