Global Styles: Add support for Google Fonts

[Copons]

Description

We'd like to make google fonts available as selectable font families in the global styles site editor experience. The legacy dotcom FSE feature, as seen below, is a good example of this.

In Progress

• Global Styles: Display font families from theme, core, and user in font family picker WordPress/gutenberg#33889
• Global Styles: Add support for google fonts in the site editor WIP jetpack#20674

Closed (Not Merged)

• WIP Phab diff that adds google font support to site editor on simple sites D65114-code
• WIP Phab diff that adds google font support to frontend on simple sites D65115-code

Done

• Site Editor: Implement a settings object filter WordPress/gutenberg#33736

Notes

• Core Gutenberg global styles doesn't support Base and Heading fonts. As a result, we probably won't support both in this dotcom-only feature.
• We do not need to support font pairs.
• See Site Editor: add WP.com Global Styles #46696 for context

Todos

• Determine how we will deploy these changes to Atomic site and how we'll keep the Simple and Atomic implementations in sync ( see link )

[jeyip]

Technical Details

• In making google fonts accessible in the site editor, we need to make four distinct changes. We need to:
  1. Add google fonts imports to an existing stylesheet or a new stylesheet
  2. Include google fonts as selectable options in the global styles sidebar
  3. Update global styles settings and global styles embedded stylesheets once new fonts are selected
  4. Modify the Global Styles sidebar UI accordingly
• Andres has described ways we can tap into "existing infrastructure" to extend functionality ( link )
  • To add google fonts imports, we can tap into the global styles styles settings key and append another stylesheet ( link ). An example of how to generate google fonts imports can be seen in legacy dotcom FSE global styles ( link ).
  • To include google fonts as selectable options, we can append to the global styles __experimentalGlobalStylesBaseStyles fontFamilies array via the block_editor_settings_all hook ( link ).
  • In adding the correct google fonts metadata to __experimentalGlobalStylesBase, it appears as if the corresponding changes to global styles embedded stylesheets will be made automatically when google fonts are selected.
  • Corresponding changes to the frontend can be made through wp_styles ( link )
  • I don't see an obvious way to modify the Global Styles sidebar UI, but I haven't checked thoroughly. I've spent most of my time wrapping my head around the flow of logic for Global styles 😅. The sidebar appears to be in the process of being refactored to leverage the new component system, but I'm not entirely sure if work on that has stalled. I'll check in with Andres tomorrow morning ( link ).

Relevant Links

• Global Styles Extensibility Add extensibility hooks to global styles infrastructure WordPress/gutenberg#27504
• Font Family Selection PR Add: Font Family picking mechanism WordPress/gutenberg#24868
• WIP Phab Diff to add google fonts to Dotcom Simple sites D64776-code

Notes

I'll try and draft a WIP PR of what implementation might look like. The biggest uncertainty is the current status of the global styles sidebar UI.

[jeyip]

More Context

There's been a hiccup! It turns out that I was mistaken about the extensibility of global styles.

• The global styles feature works by injecting information into the settings object before the block editor is initialized.
• Here is an example of the block_editor_settings_all filter and the gutenberg_experimental_global_styles_settings callback that global styles uses to add relevant data.
• I assumed said filter would be applied when loading the site editor, but that doesn’t happen. It’s only applied for the post editor.
• This happens because in site editing, global styles uses the same gutenberg_experimental_global_styles_settings callback to inject data into the settings object, but avoids hooks altogether by inlining it within site editor initialization.

Next Steps

Right now, to add google fonts to the site editor, all we'd need to do is update the settings object. Unfortunately, it looks like there isn't a way to filter it before loading the site editor. I've created a Gutenberg issue and an accompanying PR to hopefully address this. Hats off to @mattwiebe for helping out on this project.

• Issue: Site Editor: Implement a settings object filter WordPress/gutenberg#33736
• PR: Site Editor: Implement a settings object filter WordPress/gutenberg#33737

[jeyip]

I've separated adding google fonts support to dotcom simple sites into two separate phab diffs for readability -- one for site editor changes D65114-code, and one for frontend changes D65115-code. Both are ready for preliminary code review (will update testing notes tomorrow morning)

[creativecoder]

@jeyip Have you thought about how we will deploy these changes to Atomic sites, as well, and how we'll keep the Simple and Atomic implementations in sync?

I think its best if we figure this out before committing anything to wpcom (though I appreciate having the diffs to start testing).

[jeyip]

Have you thought about how we will deploy these changes to Atomic sites, as well, and how we'll keep the Simple and Atomic implementations in sync?

@creativecoder I haven't given those ideas as much attention, but that's a great question. I've been focused on making sure the extension points that we're hooking into work as expected.

I've had two approaches floating around in my head, which I assumed were interchangeable (although I haven't verified). Feel free to correct me if either of these don't actually work, if they're too simplistic, or if there are other alternatives.

Update Dotcom simple codebase + wpcomsh

Pros

• Cannot be deactivated on atomic

Cons

• Need to update multiple codebases to ensure changes propagate to simple and atomic sites

Update Editing Toolkit Plugin

Pros

• It's one codebase, so we can make changes to one place
• Changes are applied to both simple and atomic sites

Cons

• Can be deactivated on atomic

I've ruled out Jetpack because, from my understanding, this is a dotcom specific feature we're implementing.

[jeyip]

@creativecoder friendly ping to see if you have further thoughts about my suggestions.

Also wondering if others have thoughts about the best way to make google fonts support available to simple + atomic sites @Addison-Stavlo, @mattwiebe ( see link ). I'm currently leaning towards using the Editing Toolkit Plugin.

[Addison-Stavlo]

I'm currently leaning towards using the Editing Toolkit Plugin.

That seems like a good way to go about it. I wonder if its better to go ETK or Jetpack for this? 🤔

[creativecoder]

@creativecoder friendly ping to see if you have further thoughts about my suggestions.

Update Editing Toolkit Plugin

@jeyip The main problem adding new features to ETK is that about 38% of Atomic sites still don't have the plugin active (probably because they were created before it was released), so those users never see the feature. Enhanced fonts seem like a basic feature that most users expect to be available, so this seems like a major problem to me.

Another proposal I've seen recently, is to develop a package in Jetpack, and add it as a dependency of wpcomsh (p9o2xV-1um-p2). That seems worth investigating. Adding a package dependency to wpcomsh is trivial, so I think the main question is how wpcom can run such a package (preferably with out manually copying and pasting the code, of course).

That seems like a good way to go about it. I wonder if its better to go ETK or Jetpack for this? 🤔

@Addison-Stavlo you bring up a great point, which is that we shouldn't assume this isn't a fit for Jetpack. I think we should inquire about this as the next step in figuring out where to put this code.

[kraftbj]

Adding a package dependency to wpcomsh is trivial, so I think the main question is how wpcom can run such a package (preferably with out manually copying and pasting the code, of course).

WordPress.com has its own composer.json file for Jetpack packages being utilized on there. Crew can add it there. We update it whenever we're shipping new Jetpack versions, but can explore process if needed.

A Jetpack-developed package is definitely an option. Another would be to include it in Jetpack itself as an experimental block (like the other wp.com-only blocks). In any event, the Jetpack monorepo sounds like a fine place for this.

[jeyip]

Status Update

I'm pausing work on google fonts to focus on the remaining FSE beta release blockers. https://github.com/Automattic/wp-calypso/milestone/359.

I plan to return to this in the near future when the blockers are resolved, and will update this issue accordingly when things change. @Copons @vindl @creativecoder

[creativecoder]

Upcoming Core change which should make this a bit easier: https://make.wordpress.org/core/2021/09/28/implementing-a-webfonts-api-in-wordpress-core/

[vindl]

Moving this out of On Hold column since it's a priority for FSE rollout.

[simison]

PR at Gutenberg: WordPress/gutenberg#36394

[jeyip]

• Revision for dotcom simple site integration ( D74478-code )
• New simplified webfonts API gutenberg PR ( Webfonts API WordPress/gutenberg#37140 )

[creativecoder]

The “Simplified” Webfonts API has been merged (WordPress/gutenberg#37140).

We'll proceed with Automattic/jetpack#23045 to bring Google fonts support to WP.com sites, (which can start working once the feature is available from Gutenberg).

[Addison-Stavlo]

As we have released Google Fonts to simple and atomic, I am closing this issue.

A big "Congrats!" and "Thank You!" to everyone involved! 🥳 🎉 🚀

Remaining issue with some universal themes conflicts will be tracked here - [Bug]: Google fonts not appearing in Global Styles for some Dotcom Sites