Webfonts: register and enqueue fonts by font-family #39559

zaguiini · 2022-03-17T22:18:31Z

What?

Part of #39332.

Why?

It's an attempt to make the webfonts API more flexible and save transferred data. We're now registering font families (individual font faces grouped by font-family) and enqueueing them as needed.

We more closely match the behavior of wp scripts and styles and accommodate functionality that WordPress developers are already familiar with.
We allow API consumers more flexibility in how and when they enqueue webfonts, rather than forcing them to enqueue all fonts indiscriminately.

How?

We're creating a hash of the font-family attribute and grouping registered font faces to their respective font families;

We then introduce enqueueing and do not add registered font-families to the output by default -- they must be explicitly added through enqueueing. All fonts are enqueued when opening the editor so fonts picked when making changes show up correctly.

Webfonts should be enqueued after the after_setup_theme hook runs because that's where registration happens. So we should recommend hooking into init or wp_loaded to enqueue fonts since it's guaranteed to be registered at the time that these hooks are run.

Testing a webfont loaded via `theme.json`:

Using the Bennett theme as an example, we edit its theme.json file and replace fontFamilies with the following:

"fontFamilies": [
    {
        "fontFamily": "Roboto",
        "name": "Roboto",
        "slug": "roboto",
        "fontFace": [
            {
                "fontFamily": "Roboto",
                "fontWeight": "900",
                "fontStyle": "normal",
                "fontStretch": "normal",
                "src": [ "file:./assets/fonts/Roboto-Regular.ttf" ]
            },
        ]
    }
],

Then, we create a functions.php in the bennett theme directory and add the following:

<?php

add_action( 'init', function() {
	wp_enqueue_webfont( 'Roboto' );
} );

Testing a webfont programmatically through PHP:

Next, to test the PHP registration using the wp_register_webfont function, in functions.php add the following:

add_action( 'after_setup_theme', function() {
	wp_register_webfont(
		array(
			'font-family'  => 'Roboto',
			'font-style'   => 'normal',
			'font-stretch' => 'normal',
			"font-weight" => "900",
			'src'          => get_theme_file_uri( '/assets/fonts/Roboto-Regular.ttf' ),
		)
	);
} );

add_action( 'wp_loaded', function() {
	wp_enqueue_webfont( 'Roboto' );
} );

Refresh the page and Roboto should be there. You can try adding another font of the same family in italic (font-style: italic) and changing the src. It should load both fonts.

When you remove wp_enqueue_webfont, Roboto should not be loaded anymore.

lib/compat/wordpress-6.0/class-wp-webfonts-provider-local.php

lib/compat/wordpress-6.0/class-wp-webfonts.php

zaguiini · 2022-03-23T21:51:29Z

@hellofromtonya this is ready for review and adapted to your comments.

@aristath please take a look when possible 🙏

creativecoder

The overall approach is looking good and makes sense to me.

I think this is best reviewed in tandem with #39593, as the first real test is if it helps us remove unused font-face declarations to avoid unnecessarily bloating the html.

lib/compat/wordpress-6.0/class-wp-webfonts.php

lib/compat/wordpress-6.0/register-webfonts-from-theme-json.php

The API, although looking really good, is not ready for Core. So we must move it from wordpress-6.0 to experimental, and only add it there when it's ready to enter WordPress. Relocate files to /lib/experimental. Per the Gutenberg PHP > File structure documentation https://github.com/WordPress/gutenberg/tree/trunk/lib#file-structure.

Tests for methods that have a `_doing_it_wrong()` require an `expectedIncorrectUsage` annotation, proper usage of test fixture methods, and the usage of `__METHOD__` when invoking `_doing_it_wrong()`. This commit: - Fixes the test fixtures to use snake_case format and calling of the parent fixtures. - Refactors `get_font_slug()` tests into data providers (preferred in Core) and separates tests that will trigger `_doing_it_wrong()` to use the annotation. - Uses `__METHOD__` instead of `__FUNCTION__` in each `_doing_it_wrong()` instance.

The `WP_Webfonts::generate_styles()` should not be aware of how to reorganize the webfonts from grouped by font-family to grouped by provider. Why? This is a separate task from generating styles for the webfonts. This commit creates a private method called `get_webfonts_by_provider()` to encapsulate the know-how for this reorganizational work. It also includes a micro-optimization that eliminates an extra `foreach` loop and the building of an unnecessary `$webfonts` array of arrays.

hellofromtonya · 2022-04-04T12:43:19Z

Rebased against latest trunk to resolve merge conflicts.

lib/load.php

…g.php.

lib/load.php

hellofromtonya

Scope of this PR - LGTM 👍

Other changes (such as tests, wiring theme.json enqueue, etc.) will be done in other PR(s).

scruffian · 2022-04-04T16:27:45Z

lib/experimental/class-wp-theme-json-resolver-gutenberg.php

-		return $variations;
-	}
-
+class WP_Theme_JSON_Resolver_Gutenberg extends WP_Theme_JSON_Resolver_6_0 {


This file no longer seems to be loaded at all? I'd like to modify get_theme_data but I'm not sure how now...

Sorry @scruffian, what do you mean? It is listed in load.php: https://github.com/WordPress/gutenberg/blob/trunk/lib/load.php#L111.

Sorry, looks like I was stuck in a bad merge state...

bradhogan · 2022-04-14T16:23:18Z

Is this now the way fonts should be loaded into a block theme? Any official documentation on this?

zaguiini · 2022-04-14T16:25:18Z

Hey @bradley2083,

Please read #39332 (comment).

bradhogan · 2022-04-14T17:14:27Z

@zaguiini Thanks for sharing that. So I'm still not 100% clear but sounds like we still need to use font-face declarations for the time being?

zaguiini · 2022-04-14T18:16:30Z

Sorry, @bradley2083.

We now have separated registration and enqueueing of fonts, just like we have with scripts and styles.

#39988 will enqueue the fonts listed in theme.json, even if they're registered programmatically (i.e. through the wp_register_webfont method).

After that, we'll work on #40363, so we can enqueue automatically the fonts picked in global styles.

So no, you won't need to use font-face declarations. The Webfonts API should be sufficient. Right now, you can use it to register and enqueue webfonts through the API.

When #39988 gets merged, you can use solely theme.json to register and enqueue fonts. Note that the picker in global styles won't work for externally/programmatically registered webfonts, only for the fonts explicitly listed in theme.json.

This problem will be addressed in #40363, so externally registered webfonts will be considered when enqueueing fonts to the front-end.

bradhogan · 2022-04-14T18:31:46Z

Ok got it. Thanks @zaguiini I'll start to play around with using wp_register_webfont I assume this is too early to have any documentation / examples for this stuff atm?

zaguiini · 2022-04-14T18:32:55Z

Yeah, right, @bradley2083. It's not going to be included in 6.0, so too early. But the methods in webfonts.php do have some documentation. It should be straightforward to understand what's going on.

gigitux · 2022-05-03T15:32:38Z

We noticed that with the new Gutenberg versions (from 13.0) the Global Styles for WC Blocks plugin doesn’t apply anymore.

It seems that the problem is caused by this PR, in particular, this this change.

I don't have a lot of context on this part of the code. Could you take a look? Thanks!

cc @zaguiini @hellofromtonya

zaguiini force-pushed the try/register-and-enqueue-webfonts-by-family branch from b979374 to feb1de1 Compare March 17, 2022 22:25

aristath self-requested a review March 18, 2022 09:32

This was referenced Mar 21, 2022

Webfonts: remove unused font-face declarations #39332

Closed

Webfonts: scan content for webfonts and enqueue them #39399

Closed