-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fonts API] Refactor Theme JSON global functions into WP_Fonts_Resolver #50811
[Fonts API] Refactor Theme JSON global functions into WP_Fonts_Resolver #50811
Conversation
Flaky tests detected in c146215. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5083809805
|
* | ||
* @since X.X.X | ||
*/ | ||
class WP_Fonts_Theme_Json_Handler { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm rethinking this new class. Since I first wrote the issue's scope, a new resolver class WP_Fonts_Resolver
was merged into the API. I'm thinking the static functions here can be merged into that resolver class instead. Why? These methods are doing resolver work. Rather than adding another class, I propose consolidating the functionality into the resolver.
To retain @anton-vlasenko's work, I'll open a new PR but cherry-pick Anton's work as a starting point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blocking this PR from merge. A new PR will be opened to consolidate the functionality into the new WP_Fonts_Resolver
class.
As a POC (proof of concept), I created PR #50914. It does the following:
I'll now add each of the changes to this PR to keep it all in the original work @anton-vlasenko created. Tasks:
|
…istered_fonts_to_theme_json() to static methods.
…me_json to WP_Fonts_Theme_Json_Handler::register_fonts_from_theme_json.
…_theme_json to WP_Fonts_Theme_Json_Handler::add_registered_fonts_to_theme_json.
1f949e0
to
6411d24
Compare
Which fonts get added to the Theme JSON data depends on if in the Site Editor or not. Site Editor = registered fonts. Else = enqueued fonts. Renaming this method better reflects what it does.
Why? To centralize what the origin value is in one place, rather than dispersing the internal details outside of the class.
Test ReportEnv:
ResultsTesting the theme's fonts get automatically registered and enqueued into the Fonts API✅ ✅ All of the TT3 fonts have Testing plugin fonts are added to the Theme JSON data layerIn the Site Editor: ✅ After selecting the Playfair Display for headings and refreshing on the front-end:
Conclusion✅ Works as expected |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anton-vlasenko the work you did was excellent. Well done 👏
With the new WP_Fonts_Resolver, I moved your work into it, which eliminated the need for another class. Sorry for the confusion.
I've updated the PR accordingly and made a couple more refactorings.
All of the PHPUnit tests are passing ✅
Manual testing works as expected ✅
This PR is ready for merging.
Test ReportEnvironment
Actual ResultsWith TT3 only:
With TT3 and the fonts test plugin, setting the global typography for headings and text:
Additional InformationNote that as expected, block-level Typography font pickers (in site editor and post editor) also contained all registered fonts, which when user-selected, were subsequently enqueued in the frontend. This is consistent with behavior on |
Thank you, @hellofromtonya. I'm glad you like it. BTW, I've noticed a typo in this PR. Probably, this doesn't deserve a separate PR and could be fixed in one of the following PRs (it's a private method anyway). |
What?
There are 2 global functions within the lib/experimental/fonts-api/register-fonts-from-theme-json.php file that will be needed in Core as part of the API. These functions are large and doing multiple tasks, as such are difficult to debug and understand.
Why?
To improve code quality, readability, and prepare these functionality for future and Core,
lib/experimental/fonts-api/register-fonts-from-theme-json.php
and its functions need a redesign / refactoring. It's a better fit for a Core-only static class wrapper pattern (i.e. a class with static methods).How?
add_action( 'init', 'gutenberg_register_fonts_from_theme_json', 21 );
into thefonts-api.php
file and update it to use the new static method instead of the global callback function.Testing Instructions
Manual Testing
How these functions work and what they do did not change. This means the functionality should work exactly as it did for, i.e. scope of this PR should be a pure refactoring. Manual testing is focused on ensuring no changes happened to the functionality, i.e. works the same as in
trunk
.Setting up your local test site:
Testing the theme's fonts get automatically registered and enqueued into the Fonts API:
wp-fonts-local
. Expectation: It should be in the<head>
and contain the@font-face
styles for the theme's fonts.Testing plugin fonts are added to the Theme JSON data layer:
wp-fonts-jetpack-google-fonts
. Expectation: The<style>
element should be in the<head>
and the CSS in it should only contain@font-face
styles for Playfair Display.wp-fonts-local
. Expectation: It should be in the<head>
and contain the@font-face
styles for the theme's fonts.Automated Testing
Run the following:
All tests should pass.