Update Google fonts collection data for 6.9 release

[wildworks]

Main tracking core tiket: ​https://core.trac.wordpress.org/ticket/64007
Previous ticket: https://meta.trac.wordpress.org/ticket/7808

This ticket is to make the latest Google Fonts available in the font library for the WordPress 6.9 release.

The Google Fonts collection referenced by the WordPress font library depends on the ​google-fonts-to-wordpress-collection repository. Therefore, in order to update the Google Fonts data, the new font data must be hosted in the google-fonts-to-wordpress-collection repository. Furthermore, that font data must be accessible on the s.w.org domain.

The font data for 6.9 is already prepared in the google-fonts-to-wordpress-collection directory. See ​https://github.com/WordPress/google-fonts-to-wordpress-collection/pull/43

We would be happy if this font data could be hosted as follows:

This file:
​https://github.com/WordPress/google-fonts-to-wordpress-collection/blob/trunk/releases/wp-6.9/collections/google-fonts-with-preview.json
Should be hosted at:
​https://s.w.org/images/fonts/wp-6.9/collections/google-fonts-with-preview.json

This folder:
​https://github.com/WordPress/google-fonts-to-wordpress-collection/tree/trunk/releases/wp-6.9/previews
Should be hosted at:
​https://s.w.org/images/fonts/wp-6.9/previews

Example of a final url of the preview file:

​https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee.svg

cc @dd32 @mikachan

[dd32]

I've deployed the entirity of ​https://github.com/WordPress/google-fonts-to-wordpress-collection/tree/trunk/releases/wp-6.9/ to the CDN.

Trac ticket: https://meta.trac.wordpress.org/ticket/8099

[wildworks]

@dd32 Thanks for the update!

Strangely, in my environment, only the URL below is not hosted correctly. The URL is redirected to ​https://wordpress.org/:

​https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee.svg

The font data is definitely available on GitHub:

​https://github.com/WordPress/google-fonts-to-wordpress-collection/blob/trunk/releases/wp-6.9/previews/abeezee/abeezee.svg

On the other hand, all other fonts seem to be hosted correctly.

For example:

​https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee-400-italic.svg
​https://s.w.org/images/fonts/wp-6.9/previews/adlam-display/adlam-display.svg

Will it take a little longer for all URLs to be hosted?

[dd32]

@wildworks Unfortunately you loaded that URL before it was deployed to WordPress.org, and as a result, you've cached a 404/301 redirect for that path in your local CDN POP.

You should see the correct data if you were to access https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee.svg?v1 for example.

As I noted in the previous ticket: https://meta.trac.wordpress.org/ticket/7808

Please don't link to final urls, as the CDN caches the 404 indefinitely, the quoted URLs may not work consistently. That'll need systems interactions to clear the cache if required.

The CDN doesn't have any ability for WordPress.org to clear it, I'm not sure of the timeout though on the cache, it may clear by itself within a few hours, although I expect I'll have to ask systems to purge it. I know that 200 responses have a rather long cache period.

Can you provide the output of curl -I https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee.svg ?

[wildworks]

@dd32

You should see the correct data if you were to access ​https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee.svg?v1 for example.

I was able to access the font data correctly using a URL with GET parameters.

Can you provide the output of curl -I ​https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee.svg ?

Here is the output of the command on my host machine (Windows 11):

D:\> curl.exe -I https://s.w.org/images/fonts/wp-6.9/previews/abeezee/abeezee.svg
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Oct 2025 06:32:46 GMT
Content-Type: image/svg+xml
Content-Length: 3701
Connection: keep-alive
Last-Modified: Tue, 07 Oct 2025 00:11:42 GMT
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Access-Control-Allow-Methods: GET, HEAD
Access-Control-Allow-Origin: *
Alt-Svc: h3=":443"; ma=86400
X-nc: HIT nrt 1
Server-Timing: a8c-cdn, dc;desc=nrt, cache;desc=HIT;dur=1.0
X-Content-Type-Options: nosniff

The response appears to be correct, but when I access the same URL from a browser, I am still redirected to ​https://wordpress.org/.

[dd32]

@wildworks Thanks!

I've just teleported my connection to Japan, and tested against your local CDN node. I'm not seeing the redirection cached on any of the local CDN nodes, so it's likely not cached for others.

I don't want to suggest clearing your browser cache, but deleting the cached data for the domain will likely remove it from your browser cache (It's cached for 10 years). I think chrome://settings/content/all?searchSubpage=w.org will open it in Chrome. You can also check in another browser to verify if it's the browser cache :)

[wildworks]

I think chrome://settings/content/all?searchSubpage=w.org will open it in Chrome.

It seems that the cache does not exist. It shows "No sites found".

You can also check in another browser to verify if it's the browser cache :)

Strangely, the problem persists even when I change browsers or devices.

I'm thinking it might be an issue with my home network or my area...