The WordPress Web Fonts API is here – WP Tavern

0

The journey to a web font API in WordPress has been a rollercoaster of emotions for developers. After being retired from the WordPress 5.9 release, it was moved to Project Gutenberg, where it could be built with related functionality that depended on it.

The API has been merged with Gutenberg plugin and should land in version 12.8. Theme authors who want to test it can clone the dev version of the plugin or download night version from the Gutenberg Times.

Jono Alderson opened the original ticket for a web font API in February 2019. However, it wasn’t until late 2021 that it got a mass of support and development. By most accounts, the API seemed ready to ship with WordPress 5.9. However, it was put on hold by Andrew Ozz, one of the main WordPress developers.

It wasn’t a popular decision, but it might have been the best direction. The API was limited because it did not yet have theme.json Support. Being only available through PHP meant that theme authors would have mostly done what they’ve always done – deploy their own solution. It wasn’t the delay for its unveiling, but it will likely be the most common use case for the API.

While many wanted to see this feature land in WordPress 5.9, the extra months gave it time to evolve into a cleaner API that integrates with the site and content editors.

Theme authors can now define font definitions alongside their corresponding families in theme.json files, and WordPress will automatically load the necessary files @font-face CSS in the editor and on the front-end. I’ve tested this extensively and haven’t encountered any issues.

The potential downside is that the feature only comes with support from a local vendor, which means the fonts have to be bundled with the theme. A Google Fonts provider was part of the original implementation, but was later removed.

Ozz walks in more details in a previous postbut his recommendation was to drop Google Fonts support for now:

Add support only for local fonts at this time. If WordPress later decides to include support for Google’s CDN, the implementation will need to consider web privacy laws and restrictions and tie into a possible user consent API, etc.

Related article: German court convicts website owner for violating GDPR by using Google-hosted fonts

Ari Stathopoulos, one of the developers behind the Web Fonts API, explained that bundling an in-core solution that writes font files directly to the server would improve privacy:

Instead of removing it, maybe we could implement them properly, applying locally hosted web fonts to improve performance and privacy? This way we would set a good example, and we would see a significant improvement in performance and privacy across the WP ecosystem, as themes and plugins that currently use Google Fonts, Adobe Fonts and so on will start adopting the API.

For now, it looks like local fonts are officially supported, but theme and plugin authors need to register custom providers. One of the fears with the lack of Google Fonts support is that there will be many competing solutions out there instead of one solid vendor that everyone can rely on. The more developers build their own wheels, the more likely different implementations are to come with bugs or security issues.

Automattic already has a draft patch for a google provider for jet pack. Assuming this is inserted into the plugin, it will undoubtedly conflict with a theme down the road that registers its own google supplier identifier.

Only local font support could also create larger theme download sizes. For many themes, this shouldn’t be a problem. One, two or three font packages are reasonable. However, if global style variations become popular, we might see themes that offer dozens of fonts to cover multiple pre-packaged designs. This will quickly lead to bloated theme files, and combined with enough images, theme authors can hit the 10MB limit for repository submission. It sounds a bit like tomorrow’s problem, but it’s something to start thinking about today.

There are still a few issues to resolve around the API. However, pushing it early in the WordPress 6.0 release cycle will give everyone time to test it and help improve it.

Testing grouped fonts

There are two methods for registering web fonts with WordPress. For theme authors, the easiest solution is to define them via their theme.json files. This is the method I will cover below since the file has been standard since WordPress 5.8. There is a PHP example in the pull request ticket.

the theme.json keys and values ​​mostly match CSS @font-face to reign. Theme authors should brush on it if it’s been a while since they’ve used it.

For testing, I registered three web fonts through my theme, and the following screenshot shows them in action in the editor:

Testing three web fonts.

Web fonts must be saved as settings.typography.fontFamily as part of a specific font family definition. Here’s a copy of the code I’m testing in one of my themes using the Cabin font:

{
    "settings": {
        "typography": {
            "fontFamilies": [
                {
                    "fontFamily": ""Cabin", sans-serif",
                    "slug": "primary",
                    "name": "Primary",
                    "fontFace": [
                        {
                            "fontFamily": "Cabin",
                            "fontWeight": "400 700",
                            "fontStyle": "normal",
                            "src": [ "file:./public/fonts/cabin/Cabin-VariableFont_wdth,wght.ttf" ]
                        },
                        {
                            "fontFamily": "Cabin",
                            "fontWeight": "400 700",
                            "fontStyle": "italic",
                            "src": [ "file:./public/fonts/cabin/Cabin-Italic-VariableFont_wdth,wght.ttf" ]
                        }
                    ]
                }
            ]
        }
    }
}

Note that file:./public/fonts/*.ttf is relative to the theme folder. Theme authors should adjust this to fit their theme structure.

Share.

Comments are closed.