Kirki: Kirki loading cached Google font files from absolute server paths in browser

[dedalx]

Issue description:

We use kirki as a plugin on different client websites and for some of them we get the same issue - Google font files loaded by absolute paths in browser and this give 404 error.

Font loading from:
https://iamforextrader.ru/var/www/www-root/data/www/iamforextrader.ru/wp-content/fonts/rubik/iJWKBXyIfDnIV7nFrXqw023e1Ik.woff
Instead of correct url:
https://iamforextrader.ru/wp-content/fonts/rubik/iJWKBXyIfDnIV7nFrXqw023e1Ik.woff

We tried to clear transients, reinstall plugin, disable all plugins, re-save kirki settings - nothing helps. You can see issue live on https://iamforextrader.ru site.

Version used:

3.1.4

Using theme_mods or options?

theme_mods

[MapSteps]

Hi @dedalx,

Did that happen for you after you've moved the site to a different server?

Also, can you please try to delete the fonts folder in the wp-content folder to see if that fixes the issue?

Thanks!

[JiveDig]

Hey y'all, I came to report this issue as well and saw this one open. We are seeing it any time a theme customer migrates a site, which happens quite a bit from staging to live. The old url references the staging/dev site and 404's.

The only fix we've found is to delete the /wp-content/fonts/ directory which forces a re-download.

I'd vote for _not_ using absolute urls. But if there is a reason to keep them, a ! file_exists( $font_url ) check could be added which would then trigger an update of fonts/files/urls. We'd need some way to make sure that doesn't keep firing if there is an issue downloading the font, or something like that, but 404'ing font files are definitely causing issues.

We've considered adding our own "Flush fonts" button in the Customizer, but wanted to get feedback here first to see if there could be a fix in Kirki core.

Thanks for looking :D

[JiveDig]

Hey y'all. Any interest in getting this one changed/fixed? If for whatever reason it's going to stay as-is, I'm going to have to build our own fix in our engine plugin. We're getting a few reports on this now when theme customers switch servers or go from staging to live or vice-a-versa.

[fedeisas]

@JiveDig is there any chance to load fonts directly from CDN?

Found this somewhere but doesn't seem to be a valid filter anymore.

add_filter('kirki_use_local_fonts', '__return_false');

Just wondering why CDN was disabled on the first place, maybe I'm missing something. Thanks.

[aristath]

The CDN was disabled because of GDPR and performance.
Locally loading webfonts is faster, more secure, and most of all does not violate any laws in any country - which is not always the case with the CDN. Additionally, some countries block google CDNs so locally hosting the webfonts fixes typography for everyone.

[fedeisas]

The CDN was disabled because of GDPR and performance.

Locally loading webfonts is faster, more secure, and most of all does not violate any laws in any country - which is not always the case with the CDN. Additionally, some countries block google CDNs so locally hosting the webfonts fixes typography for everyone.

I'm running on a distributed read only environment. Writing to disk could be optional. I don't think my server is any faster than Google's CDN?

[aristath]

Performance is not just about who has the fastest server.
When an asset is hosted on a different domain, the browser has to make 4 additional handshakes with that server on order to verify it's ssl certificate before it even starts downloading the asset.
That's 4 round-trips just to see if it can download the font.
With the font hosted on the same domain, it just goes straight to download it.
Additionally, a basic apache server is pretty fast when it comes to serving static files... There's practical zero delay and a CDN is not as good as you might think.

[JiveDig]

We've noticed a noteworthy speed improvement since switching to self-hosted fonts via Kirki, FWIW 🙌

[fedeisas]

@aristath I agree with all of your points. Serving local fonts is the sanest default.

I just think that an opt-in way to avoid writing to disk and just embedding Google's CSS would be useful for some users.

Maybe my use case is a corner case: my theme already uses fonts from Google Fonts and I have a multi-instance deploy, so relying on the fonts/ folder is not ideal. I already have a network-shared uploads/ folder, so I'll treat fonts/ just the same.

[aristath]

In case it can't write the fonts to the filesystem it will automatically fallback to the cdn.
As for opting-in, all laws and regulations (included but not limited to the GDPR) state that privacy should be opt-out, not opt-in.
If your theme is forcing you to use the Google cdn, then they're doing it wrong and without respecting your visitors privacy.
The fact that a lot of WordPress themes and plugins are doing it wrong doesn't mean that this framework should too.
The implementation included in kirki is fast, secure, improves performance and enhances privacy. In case it's technically impossible to locally host the webfonts, nothing breaks.
It will not become opt-in.

[fedeisas]

In case it can't write the fonts to the filesystem it will automatically fallback to the cdn.

I made my fonts/ directory non-writable and this happens:

In case it's technically impossible to locally host the webfonts, nothing breaks.

I'm now serving from CDN but also downloading everything from Google on each request. While it is not broken, it's non-optimal.

As for opting-in, all laws and regulations (included but not limited to the GDPR) state that privacy should be opt-out, not opt-in.
If your theme is forcing you to use the Google cdn, then they're doing it wrong and without respecting your visitors privacy.

All in favor. This should be the plugin's default. But you are creating a hard requirement for this amazing plugin, just by assuming I won't take care of GPDR compliance elsewhere. In my case, I'm planing on using something like https://blog.cloudflare.com/fast-google-fonts-with-cloudflare-workers/ to proxy my calls to Google Fonts (https://github.com/google/fonts/issues/1637).

It will not become opt-in.

As a last resort, is there any chance we can filter this path then? Again, I'm not arguing GPDR here, I'm arguing the hard requirement that wp-content/ folder should be writable at all times.

# modules/webfonts/class-kirki-fonts-downloader.php
// If the fonts folder don't exist, create it.
if ( ! file_exists( WP_CONTENT_DIR . '/fonts' ) ) {
    wp_mkdir_p( WP_CONTENT_DIR . '/fonts' );
}

[aristath]

There are plans to replace the current implementation with the one from https://make.wordpress.org/themes/2020/09/25/new-package-to-allow-locally-hosting-webfonts/. When that happens, the path will soon be filterable.

[JiveDig]

That package looks cool. Is a reply/solution/fix for the OP waiting on the outcome of WP core using the new package?

We're still stuck manually helping customers (deleting the /fonts/ directory) when the domain changes, due to storing and relying on the absolute url to the fonts files.

[aristath]

Yeah, that package fixes the path issue 👍

[fedeisas]

@JiveDig maybe you can filter the kirki_downloaded_font_files option and replace your paths there?

@aristath I ended up setting an NFS folder for this and it works fine. No need to filter the path.