Google Fonts: Integrate with new font library

[arthur791004]

Related to Automattic/wp-calypso#81875

Proposed changes:

• As suggested, we served the collection of the Jetpack Google Fonts on wpcom. The collection is generated via the generate_google_fonts CLI tool on wpcom.
• Next, this PR gets the collection data from the remote and injects the fonts to the default global styles settings on the fly by the wp_theme_json_data_default hook so we can display Google Fonts in the dropdown of the Font Family.
• Why the default?
  • The theme global styles will be overridden after people pick any style variation. It leads to the font family from the theme global styles disappearing. Hence, it would be better to use the default global styles instead of the theme. See https://github.com/Automattic/dotcom-forge/issues/3162, Site Assembler: Fonts on Global Styles only following the pre-set from the Site Assembler, not the actual list available on WordPress.com wp-calypso#78605 for more context.
  • There is a WIP PR to allow developers to register the default fonts and display them in the “Default Fonts” section. The benefits are the default fonts are activated by default and cannot be configurable. So, when this module is deactivated, the fonts provided by this module won't stick in the user's global styles settings. However, the default fonts are invisible on the block settings as the block settings pick font families from one of the origins. But I assume it's acceptable for now since the user will only see the installed fonts there if they install a font. As a result, I think it makes to inject them into the default now (The issue is resolved 🎉)

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

• Create a Jurassic Ninja sandbox against this PR.
• Install the latest Gutenberg, e.g.: v16.7.0-rc.1
• Go to /wp-admin/admin.php?page=jetpack_modules to activate the “Google Fonts (Beta)” module
• Go to the Site Editor
• Select Styles > Typography > Text > Font
• Ensure you're able to see all Google Fonts in the list
• Disable the Gutenberg plugin
• Select Styles > Typography > Text > Font again
• Ensure you can still see all Google Fonts in the list

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the feat/google-fonts-with-new-font-library branch.

• To test on Simple, run the following command on your sandbox:

  bin/jetpack-downloader test jetpack feat/google-fonts-with-new-font-library
  

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team Review" label and ask someone from your team review the code. Once reviewed, it can then be merged.
If you need an extra review from someone familiar with the codebase, you can update the labels from "[Status] Needs Team Review" to "[Status] Needs Review", and in that case Jetpack Approvers will do a final review of your PR.

---

Jetpack plugin:

• Next scheduled release: November 7, 2023.
• Scheduled code freeze: October 30, 2023.

[pbking]

At first shake I notice:

Enabling and dis-abling this module causes the fonts introduced by this module to stick around.
Changing what fonts are in the list don't cause fonts added to be removed from the Global Styles list.
It did seem to remove them from other lists?

I didn't test a lot of scenarios though, just tinkered with it for a bit.

Ultimately this seems like a lot of logic in place for something the Font Library should be doing; I'm concerned that if this is they way Jetpack would augment the Font Library then the pipes to work with the Font Library aren't quite right yet. I would rather try to do this more simply while the Font Library is relatively malleable.

Ideally:

The module could provide a list of fonts to make available with a .json file.
These fonts point to remote locations for the assets (as outlined here)
to take advantage of publicly available CDNs OR
(I think more useful) include local references to the fonts (just like themes do).
(just as with themes) changing the collection in the .json file changes what fonts are available to the user.
Fonts that the user has used in content or Global Styles settings are automatically activated.

[arthur791004]

Enabling and dis-abling this module causes the fonts introduced by this module to stick around.
Changing what fonts are in the list don't cause fonts added to be removed from the Global Styles list.
It did seem to remove them from other lists?

Yes, so I'd prefer to keep the Google Fonts invisible on the Font Library modal in the current iteration to avoid people controlling the fonts from the Jetpack. I'm not sure whether the Google Fonts module has to remove the added fonts from the Global Styles when disabling this module (and is it possible?).

The module could provide a list of fonts to make available with a .json file.
These fonts point to remote locations for the assets (as outlined here)
to take advantage of publicly available CDNs OR
(I think more useful) include local references to the fonts (just like themes do).

Yep, I just noticed we have the collection of the JSON file but my concern is the downloadFromUrl might be changed by Google. Is it correct? Or is the asset URL available forever?

Maybe keeping the font assets in the Jetpack repo makes more sense but I'm unsure whether Jetpack allows us to add those font assets 🤔

[arthur791004]

@pbking I've created a JSON file of the font collection here and now this module loads the data from the remote and injects the fonts we want to the default global styles settings!

[pbking]

Calling this "WordPress 6.3 compatible" isn't exactly correct.
It's more accurate to say that it's "Gutenberg Fonts API compatible" (since the API it leverages is available only in Gutenberg, that library MAY be available in other versions of WordPress, etc)

[pbking]

The Font Library won't be available in WordPress 6.4 since it's currently only available in Gutenberg. It's planned to be available in WordPress 6.5. However this technique IS available in situations other than WordPress 6.4 (or 6.5).

[arthur791004]

Are there any changes I have to make here? I made a change to only check the WP_Font_Face class as I assume we still rely on it to generate and print font styles. WDYT?

[pbking]

The class isn't actually used or depended on at all as the logic exists now, WP_Font_Collection WAS used but now that collection data is just loaded manually and the class isn't needed. The data provided in that file that is loaded is everything needed for the fonts to work; no extra logic needed. That allows the logic to be font library/api agnostic. Doing it like this means that it ONLY works in Gutenberg, wereas it COULD work WITHOUT Gutenberg. Considering that it HASN'T worked without Gutenberg in the past I don't know if that matters though.

So I guess the answer is "If you want this to work WITHOUT gutenberg it CAN you'll just need to change that if() logic a bit." "If you don't care for this to work without Gutenberg then it's fine and dandy as it is"

[arthur791004]

Okay. I'll leave it as it is since it hasn't worked without Gutenberg in the past. I'd prefer to make it work without Gutenberg after WordPress 6.5 or above which supports the WP_Font_Face class.

[jeherve]

This tests well for me, and the changes make sense. I left a few nit-picks below, but nothing blocking (maybe the links, since we really try to stay away from private links in public repos in general?).

[arthur791004]

I left a few nit-picks below, but nothing blocking (maybe the links, since we really try to stay away from private links in public repos in general?).

Oh yes! We have to 👍