mlwilkerson

Hi @duuuda, sorry, this plugin does not yet support the WordPress Full Site Editor.

Hi @mappians. I cannot tell from your description whether you are using this Font Awesome official plugin. If you are, then you can use the Icon Chooser to select icons. It has a search feature that allows to you search icons easily, using the same search service as our icons gallery at https://fontawesome.com/icons

See the screenshots in this plugin’s readme in the plugin’s directory to see how you can use the plugin’s Icon Chooser:

https://www.ads-software.com/plugins/font-awesome/

@turkeybucket and @theape, this plugin can be used to load any version of Font Awesome 6 (and most versions of Font Awesome 5). It is not locked to Font Awesome 6.2.1. In fact, if you use it with a kit, it will use whatever version of Font Awesome that kit is configured to use. That could even be “6.x”, which causes it to always, automatically use the latest version of Font Awesome 6.

Hi @sadiyajiru. If this is still a concern, I’d need more information in order to provide any guidance.

It sounds like you’re using Elementor, right? If so, are you using Elementor alone to load Font Awesome? Or are you using this plugin?

If you’re using Elementor and not this Font Awesome plugin, then your question is not related to how this plugin works. If you are using both plugins, then you probably should not. As far as I know, Elementor is not designed to cooperate with this plugin–it has its own way of loading Font Awesome.

Hello, @fuchs1981. I understand that you’re asking about how to self-host Font Awesome on WordPress, without using this plugin. Specifically, you’re asking whether your code snippets need to be placed in the functions.php of the parent or child theme, and also where in the filesystem the assets should be placed.

That question pertains to WordPress development in general, and does not pertain to this plugin. So I’ll close this topic as “not a support question”.

Since that’s beyond the scope of this plugin’s support, I’ll close this forum topic.

If you have a Font Awesome Pro account, you can get support by emailing hello at fontawesome dot com.

Hi @akourkou. Based on the screenshots you provide, my educated guess is that there was some change in the configuration of your WordPress sever. If you use a hosting provider, they may have changed something.

In all of those screenshots, the browser has tried to communicate with the Font Awesome plugin’s running on your WordPress server through the WordPress REST API, and has experienced some failure. That kind of failure is not something that would be caused by the plugin, but would be caused by the way your WordPress web server is configured. For example, if you have a hosting provider who added some web application firewall rules that are too restrictive–disallowing PUT and POST http requests to those WordPress REST API endpoints, this would explain all of those errors.

I would recommend looking into that sort of thing.

If you have a Font Awesome Pro account, you can get additional support by emailing hello at fontawesome dot com.

Hi @jugiii. The plugin is tested and known to work with WordPress 6.3.2. There must be some other factor that is causing the error. I would recommend deactivating, deleting, reinstalling, and re-activating the plugin.

If you have a Font Awesome Pro account, you can get more help by emailing hello at fontawesome dot com.

Hi @iyield. We do not plan to enable Font Awesome 6 from a CDN in the same way we did for Font Awesome 5 Pro or Font Awesome 6 Free (i.e. we don’t plan to make it available in the plugin’s “Use CDN” tab).

If your interest is for the sake of seeing Font Awesome 6 Pro load from a CDN for performance reasons, then the “Use a Kit” option provides that. Kits are CDN-powered–it’s just different CDN that works in a way specific to kits.

If your interest is something else, I’d be interested hear more about your use case.

Thanks, everyone, for posting suggestions and workarounds. I’m taking all of this as feedback about what kinds of challenges and errors may result from other plugins using the Font Awesome plugin as a library, so I can consider what improvements we might want to make in the future.

As for the concern about a possible typo–foRtawesome versus fonTawesome–well, that’s become a classic point of confusion. It’s not a typo.

Long ago in an internet far away, the company who made the product called FoNT Awesome also made a product called FoRt Awesome. The organization name of “@fortawesome” (with an R) was also established for packages in registries like NPM. For example, our React component here, is @fortawesome/react-fontawesome. More relevant to WordPress, our WordPress plugin is available from the packagist registry as fortawesome/wordpress-fontawesome.

The “fortawesome” part of these package names indicates the “organization scope”, which does actually use the R. So that’s legit.

When you see this:

../wp-content/plugins/booked/vendor/fortawesome/wordpress-fontawesome

…it’s expected. It probably means that the “booked” plugin is using the package called fortawesome/wordpress-fontawesome as part of its software bundle.

Again, this is just to say that it’s not a typo, so a typo is almost certainly not the cause of the fatal error problem.

The fatal error problem is almost certainly due to the state of plugin’s settings stored in your WordPress database being in an inconsistent and/or incompatible state as a result of some confusion between the version of the Font Awesome being bundled by the “booked” plugin versus those that might be loaded by you directly, or by other plugins.

There are multiple levels of magic in this plugin to handle automatic updating and/or upgrading to provide a smooth experience. This scenario seems to be highlighting some dark corner case where all of the magic fails. I will need to level up!

Thanks for the report. I went to go open an issue for this on GitHub and found that one had already been created!

Alright, this is on my radar. I’ll close this support topic, but leave open the GitHub issue to track it to completion.

Hi @ndau15 the best and most timely way to receive support for Pro customers is to contact Font Awesome support: hello at fontawesome dot com.

I’ve most often seen that error message occur when your WordPress server is configured in such a way that it rejects REST API requests of the kind our plugin’s front-end user interface tries to send to your server (here and here are similar problems with additional comments and troubleshooting).

Your WordPress server must allow both PUT and POST requests to this plugin’s REST API routes: /wp-json/font-awesome

Hello, it sounds like the same kind of problem as discussed in this related issue: some other plugin is using Font Awesome as a dependency, and there’s a problem with it. The solution would involving figuring out which other plugin that is and disabling or resetting it.

Ok, that sounds like a problem with that Notifications module causing an unintended side effect.

The Font Awesome modal is implemented as a standard WordPress modal. I’m not sure whether there’s anything I could do to block another plugin like this from causing such an unintended side effect. I went looking for any relevant source about key event handling related to Notifications in the jetpack GitHub repo and didn’t find anything (maybe this is a premium/private module that’s not part of the GitHub repo?) I was hoping to find how they’re handling to the keyUp or keyDown event to see if maybe adding some other CSS class on our modal would avoid whatever key event handler JetPack might be binding to our modal. No luck on my attempt to track that down, though.

Hi @ravanh, I was not able to reproduce this using a clean install of WordPress 6.1.1, the default block editor, Twenty Twenty-Three, and the Font Awesome plugin version 4.3.2. I tried searching with all of the following: nose, Nose, pint, piNt. The modal did not close in any case.

Are you installing a different version of Gutenberg than is present as the default / built-in block editor in WordPress?

Perhaps there’s something else about your scenario that is causing this behavior. If you could provide any more details about how I might reproduce it, I could take a closer look.

Hi @tomaston,

If you’re using an SVG kit with this plugin, and you’re still seeing all.css and woff2 files loading, it seems most likely that there’s some other plugin or theme that is also loading Font Awesome, and doing so using the Webfont/CSS technology.

SVG Kits don’t cause any CSS or WOFF2 files to load.

This plugin’s Conflict Detection Scanner (in the Troubleshoot tab) might help you to identify and block the loading of other, conflicting versions of Font Awesome on your web site.

If you have follow up concerns, the best way to get support as a Pro subscriber is to email at hello at fontawesome dot com.