mlwilkerson

Could you be more specific about what you want to avoid when you refer to requests to the Font Awesome website? And can you show screenshot examples of where the current behavior is different from what you want?

This plugin makes zero requests to any fontawesome.com subdomain on the back end. On the front end, by default, it simply loads a Kit. Kits have their own CDN which includes multiple layers of caching, including:

1. browser disk cache
2. Cloudflare cache

As of this plugin’s version 5, when you only use the Block Editor to insert icons, they are added as inline SVGs. The only other asset that is loaded is a CSS file from your own WordPress server. You can use a hook to disable the loading of the kit entirely (see docs here). This results in zero requests to the Font Awesome Kits CDN, even on front end page loads.

Done. I’ve updated the status in the plugins directory.

Testing is good for WordPress 6.9.

Update: I’ve got a prototype implementation that adjusts the allowed_html filter for our <svg> elements. Would you be able to try an experimental pre-release?

Thanks for the report, @xariklios. I’m was not able to reproduce the error using your reproduction steps. So it seems like there must be some additional factor at play. I suspect that it’s because on your system, your Editor user does not have the unfiltered_html capability. If so, and if your KSES filter does not allow <svg>, which it probably doesn’t, then that would cause this problem.

I attempted the reproduction like this:

1. Clean install of WordPress 6.8.2
2. Install version 5.1.2 of the Font Awesome plugin
3. Add a test-editor user with Editor role
4. Login as test-editor
5. Create a post in the block editor
6. Add a Font Awesome icon block using the icon chooser (success, no console errors)
7. Publish that post (no errors)
8. View that new post on the front end (no errors, icon displays as expected)
9. As the same test-editor user, navigate back to the post listing page and click to Edit that same post
10. The icon block renders as expected within the block editor, with no JavaScript console errors.
11. Click to modify that icon–changing it’s color, size, and flip.
12. Re-save the page
13. View it again on the front end (shows expected modified icon, no errors)

On my system, users with the Editor role do have the unfiltered_html capability. Can you determine whether your users with the Editor role have the unfiltered_html capability?

@alit93 Thanks for the report. I’m on it. Will update when I find something.

After giving it some further thought, the risk may be low enough to omit our plugin’s explicit dependence on tinymce as a way to work around what I currently believe is an error in Toolset’s code. Would you join me in an experiment?

I’ve posted a development release here in our GitHub repo. It simply omits our plugin’s explicit dependence on wp-tinymce. Otherwise, it’s functionally equivalent to the 5.1.1 version of the plugin that I also released today (the curious can see diffs here).

For the bug as I was able to reproduce it above, this resolves it.

It would be helpful if those who’ve encountered the problem could try this development release, perhaps on a staging or development site, and let me know if it resolves your manifestation of the problem.

To try it:

1. Navigate to the Release Page in GitHub.
2. Click link to download font-awesome-5.1.2-1.zip from that page.
3. In WordPress admin, go to install a new plugin, click to Upload, and upload that zip file to install it.

I’ve back filled the Changelog in the readme.txt for 5.1.0. Too little too late, perhaps.