FEATURE: option to serve locally

[mlwilkerson]

From the WordPress support forum, there is a request to self-host Font Awesome Pro, rather than using the CDN.

This idea is currently moving in quite a different direction from our intent for the plugin, so it currently doesn't seem like a feature we'll be adding. But I'll leave it open for now to collect additional feedback that the community may have for us.

[My1]

what IS the intent of the plugin then? I mean isnt it basically just serve FA in a simple manner that doesnt break stuff? I personally am not a big fan of CDNs and stuff and try to keep external content low and having a local option or whatever would be pretty awesome

[mlwilkerson]

@My1 yes, serving in a simple manner that doesn't break stuff is at the top of the list of goals for this plugin.

Another goal is providing a comprehensive load of Font Awesome so that other themes or plugins can rely on this as an "icon service." That's related to the goal of "doesn't break stuff."

One of the main reasons that Font Awesome icons get broken in the WordPress ecosystem is because many themes and plugins try to load their own versions. When multiple conflicting versions of Font Awesome are loaded, icons can break, or otherwise function in unpredictable ways.

So one part of a comprehensive solution is to load Font Awesome in such away that can serve the purposes of whatever themes or other plugins may be installed.

It is easier to load and maintain a consistently working and comprehensive system to load from CDN. Most of the time, that will also result in the best performance for your web site as well.

In order to maintain the level of ease-of-use that we'd like for this plugin, while also providing that kind of comprehensive solution, I think that supporting self-hosting (serving locally) would require that the plugin automate the retrieval and storage of icon assets, and removal of unused ones.

Font Awesome users can always take a self-hosting approach if they prefer. On WordPress, you could do a custom installation setup instead of using this plugin. You'd have to do your own file management and conflict detection and resolution.

Adding this feature is not out of the question. I'm still listening for feedback to help prioritize it appropriately.

[ErinPo]

There is a GDPR-based incentive for hosting locally to avoid legal issues.

Is it possible to accomplish subsetting with local hosting of pro assets manually?

[My1]

Font Awesome Subsetter. https://blog.fontawesome.com/desktop-subsetter-beta/ including into WP could be done via a (child) theme

[mlwilkerson]

See also: https://wordpress.org/support/topic/needs-localhost-option-for-gdpr-compliance/

[alfredonodo]

Hello, do you have any news? It is very important to be able to install fonts locally in order to comply with the GDPR. Thank you

[My1]

especially with the semi recent outbreak of what basically is a Cease and desist against websites that use google fonts, and font awesome likely is in a similar situation, where website owner could get in trouble if using them from online

[mlwilkerson]

@alfredonodo and @My1 : This is still on my radar as a feature that I'd like to get added. Internally at Font Awesome we're making some changes to our infrastructure that would make this more achievable using the plugin. However, I can't offer any ETA or a guarantee that a self-hosting feature will be added to the plugin.

So if self-hosting to avoid CDN usage is necessary in your case, then your best bet is to set that up manually apart from this plugin.

Cross-posting the following:

One way to get the assets needed for self-hosting is from the download .zip file available for each release. If you have a fontawesome.com account, the download would be available from your account page. There are other ways of getting the assets for Font Awesome Free, such as the GitHub repo.

One of the ways you could setup self-hosting on WordPress would be follow a pattern similar to these docs. Except that wherever you see URLs in the docs that refer to CDN locations, you’d use URLs that refer back to your own web server–to the locations where you’re self-hosting the Font Awesome assets.

[alfredonodo]

@mlwilkerson I found this plugin wp font awesome that works well (now my website does not load any external link as fontawesome and cloudflare) and it is open source. Maybe you could have a look on it.

[cpiber]

Here is a temporary solution I found, assuming you have a theme you can modify (this is for webfonts):

/**
 * Register font-awesome before FontAwesome plugin can to avoid GDPR
 */
function enqueue_fontawesome() {
  $folder = \get_stylesheet_directory_uri() . '/fontawesome-free-6.1.2-web/css';
  \wp_enqueue_style('font-awesome-official', "$folder/all.min.css", null, null );
  \wp_enqueue_style('font-awesome-official-v4shim', "$folder/v4-shims.min.css", null, null );
}
\add_action('wp_enqueue_scripts', __NAMESPACE__ . '\enqueue_fontawesome', 5);

This registers the style-sheet handles the plugin uses and substitutes local files. Assumes the 6.1.2 zip is extracted in the theme folder. Could be done similarly in a plugin.

[mlwilkerson]

PR #223 proposes a way of using the plugin and loading Font Awesome that does not use the CDN for front end page loads.

It does still use Font Awesome's CDN and API service on the back end when editing content and configuring the plugin.

This non-CDN mode is related to proposed enhancements to WordPress block editor support. (There are limitations. See below.)

The principle is that it uses the Icon Chooser in the block editor to directly insert inline <svg> elements into blocks. Thus, on front end page loads, the SVG icons are present as <svg> in the page content. The only additional resource required is the SVG stylesheet for styling the SVGs.

WordPress filters can be used in PHP to:

1. Skip the enqueue of the kit. So the kit is never loaded from the CDN. Loading the kit in the browser is not necessary for rendering inline SVGs.
2. Retrieve the SVG stylesheet from the CDN at configuration time (when an admin changes the plugin's settings), and store it on the WordPress server for self-hosting.

Thus, inline SVG icons are rendered with appropriate styling without any dependence on a CDN for front end page loads.

Limitations

This mode does not work for icons made with <i> tags or [icon] shortcodes (which currently just produce <i> tags). So it won't work for icon content produced in the Classic Editor, or any other editing environment other than the block editor. (It would work in general wherever you "edit as HTML" and manually paste inline SVGs that include the appropriate CSS classes for styling.)

A significant feature of this plugin is the Conflict Detection Scanner to detect conflicting versions of Font Awesome. It's common that a WordPress site will include a theme and/or a collection of plugins that each try to load their own version of Font Awesome, resulting in conflicts. The Conflict Detection Scanner can be used to find those, and try to block them from loading, so that only the user's preferred version of Font Awesome (selected by this plugin) is loaded. Yet, because those other plugins normally use Font Awesome via <i> tags or CSS pseudo-elements, their icons still work using the Font Awesome installation normally loaded by this plugin.

PR #223 does not address those compatibility concerns at all. If you were to use the Conflict Detection Scanner to block all conflicting loads of Font Awesome, and then you also used the new WordPress filter to block the loading of this plugin's configured kit from the CDN, then there would be NO version of Font Awesome loaded globally that could render the icons for the <i> tags used in those other plugins.

That won't be a problem if you only care about using the block editor. It also won't be a problem if you're satisfied with letting those other plugins just keep loading their various versions of Font Awesome and let what happens happen with those conflicts. Simply don't block any of them, and let them continue doing whatever they're doing.