kirki: Major issue - Kirki Fonts not working (woff files not being rendered)
Issue description:
I suspect that whatever mime type Kirki used to rely on to get woffs is no longer working. Fonts are loaded as octet-streams.
Version used:
5.0.0
Using theme_mods or options?
theme_mods
Code to reproduce the issue (config + field(s))
Load ‘Inter’ within a typography control, and look within web inspector (Network > Fonts) to see the file type of the font loaded.
I noticed something strange in web inspector this week:
Rather than woff files appearing, fonts from Kirki were rendered as octet-streams.
From researching this a bit more, if a font does not have a MIME type it takes a Content-Type: binary/octet-stream instead of application/font-woff.
This is the code Kirki uses to retrieve Google fonts:
/**
* Get remote file contents.
*
* @access public
* @since 3.1.0
* @param string $url The URL we want to get the contents from.
* @param string $user_agent The user-agent to use for our request.
* @return string Returns the remote URL contents.
*/
public function get_url_contents( $url = '', $user_agent = null ) {
if ( ! $user_agent ) {
/**
* The user-agent we want to use.
*
* For woff2 format, use'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0'.
* The default user-agent is the only one compatible with woff (not woff2)
* which also supports unicode ranges.
*/
$user_agent = 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8';
}
// Get the response.
$response = wp_remote_get( $url, array( 'user-agent' => $user_agent ) );
// Early exit if there was an error.
if ( is_wp_error( $response ) ) {
return;
}
// Get the CSS from our response.
$contents = wp_remote_retrieve_body( $response );
// Early exit if there was an error.
if ( is_wp_error( $contents ) ) {
return;
}
return $contents;
}
I tried a proof of concept, changing it to:
public function get_url_contents( $url = '', $user_agent = null ) {
/**
* The user-agent we want to use.
*
* The default user-agent is the only one compatible with woff (not woff2)
* which also supports unicode ranges.
*/
$user_agent = 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8';
// Switch to a user-agent supporting woff2 if we don't need to support IE.
if ( 'woff2' === $this->font_format ) {
$user_agent = 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0';
}
// Get the response.
$response = wp_remote_get( $this->remote_url, array( 'user-agent' => $user_agent ) );
// Early exit if there was an error.
if ( is_wp_error( $response ) ) {
return '';
}
// Get the CSS from our response.
$contents = wp_remote_retrieve_body( $response );
return $contents;
}
A key change is the user_agent.
$user_agent = 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0';
Ensures we just get woff2 files (which do load correctly).
My guess is that seeing as woff2 support is basically assumed at this point, Google has stopped sending back .woff files when the older user agent is used - and instead you see this octet-stream version.
A major issue arises when trying to load the popular ‘Inter’ font within the typography control in Kirki. The octet-stream version of it doesn’t render at all.
I’d really appreciate it if Themeum looked into this.
About this issue
- Original URL
- State: open
- Created 4 months ago
- Reactions: 15
- Comments: 35 (1 by maintainers)
Hey there,
David here, former owner of Kirki. I’ve pinged the Themeum team about this. Hope we’ll get a fix for this soon!
It seems like a quick fix for this issue is to change the user agent as suggested above:
Then delete the
kirki_remote_url_contentstransient:Then everything should work using .woff2 files instead of .woff files - at least until Google changes something again…
Clean transients
kirki_remote_url_contentsThanks for the solution.
We had the exact same issue with the popular Poppins font.
The interim solution outlined above fixed it too.
Step by step
1. In: /plugins/kirki/kirki-packages/module-webfonts/src/Webfonts/Downloader.php
Commented out line 186: //$user_agent = ‘Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8’;
Added line: $user_agent = ‘Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0’;
2. In: Wordpress backend.
Installed plugin: ‘Transients Manager’ and activated it on affected websites in the Wordpress Multisite.
3. In Wordpress backend.
Went to: Tools > Transients.
Searched for: kirki.
Deleted: kirki_remote_url_contents
There was update for Kirki released 2 hours ago, seems they have fixed that, thanks!
To fix the issue faster on all our websites we composed a simple plugin that can fix this. Download here. Simply install and activate it, after that you can delete it. Be aware that we haven’t tested it on all setups, so use it at your own risk.
I notice that some of the comments seem confused about how to get woff2 fonts working. If you’re experiencing this issue and trying to change the user agent to get woff2 fonts, you also need to delete the transient
kirki_remote_url_contents. Note that Kirki’s “Clear Font Cache” button does not do this.You can delete the transient using the (WP-CLI) command I listed above, or, if you aren’t able to run the command, you might be able to delete it using the Transients Manager plugin that was suggested here.
Or you can wait until the transient expires on its own - but that may take up to 7 days.
This works for my sites.
STEP BY STEP
Wordpress admin option (copy and paste on your browser):
/wp-admin/plugin-editor.php?file=kirki%2Fkirki-packages%2Fmodule-webfonts%2Fsrc%2FWebfonts%2FDownloader.php&plugin=kirki%2Fkirki.php
FTP Option:
/plugins/kirki/kirki-packages/module-webfonts/src/Webfonts/Downloader.php
Commented out line 186: //$user_agent = ‘Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8’;
Added line: $user_agent = ‘Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0’;
Wordpress admin option (copy and paste on your browser):
Notice: Take care with your customs fonts on this folder: /wp-content/fonts/ kirki will delete and download all fonts again so, your custom fonts in this folder will delete by kirki, recomendation is upload your custom fonts on your own folder in your child theme.
/wp-admin/options-general.php?page=kirki_settings and clear cache (if you are using other aditional option for cache, clear it after kirki cache)
And all fonts will be works!
This works for all our sites, I hope this fix you fonts issue.
Bye.
The change of user agent here is at best a bandaid, and technically makes Kirki less backwards-compatible with browsers that don’t support woff2, but that’s only somewhere around 2.42% these days
The real issue is that Kirki is always expecting
@font-face{ src: }URLs to be in this format:Whereas the changed behaviour from Google sometimes returns URLs like this:
In testing a few weeks ago, I would sometimes see this 2nd style of URL even for woff2 files, and my suspicion is that less-frequently-accessed fonts return URLs in the 2nd form, so this user agent change isn’t guaranteed to always fix the issue for all fonts. (Testing again today, I get woff files in the 1st format, so Google may have made a change on their end now)
The assumption in the code that breaks with this 2nd URL format is here: https://github.com/themeum/kirki/blob/b807cfbef1224527632c7282bc867478ed1bd8f2/kirki-packages/module-webfonts/src/Webfonts/Downloader.php#L89
This will always return the string
fontfor the new URL format, the result being that all font files get saved as/wp-content/fonts/font-family/font, each new file saved overwriting the last, leaving only whatever file is downloaded last to be referenced by all variants. The last file downloaded will often be for a small unicode range, so the end result is a browser falling back to the next font in the font stack for most characters.The real fix here could be as easy as changing the above line to something like:
in order to hash the URL uniquely and not worry about exactly what format it takes.
The 5.1.0 update does not seem to fix the font loading issues, fonts are still not loading correctly on any of my sites using the latest version
Same issue there with my WordPress themes from themeforest
Thanks for the solution.
@simontomkins Can we have issue title edited to something like — Google Fonts Or Kirki Fonts not loading/working? That will catch the attention of team, as it is major issue and need a patch as early as possible. Thanks.