-
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
[WIP] Change Webfonts API architecture to use Core's Dependencies API #42946
[WIP] Change Webfonts API architecture to use Core's Dependencies API #42946
Conversation
Benchmark: Average Processing Time
Ran on 3 Aug 2022Results:
Ran on 17 Aug 2002Commits used: Results:
|
Using the POC, makes the register and enqueue work. Reworks the `do_items()` and `do_item()` to process each provider's fonts, rather than font-by-font. Adds a `print_styles()` method to the base Provider. Why? To give each provider control its HTML tag and styles.
a745dcf
to
1425f32
Compare
|
||
foreach ( $webfonts as $webfont ) { | ||
$slug = wp_register_webfont( $webfont ); | ||
foreach ( $webfonts as $font_family => $variations ) { |
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.
The PoC changes the structure of the $webfonts
array as now the variations must be a multi-dimensional array keyed by its font-family
.
Previous structure:
array(
array(
'provider' => 'local',
'font-family' => 'Source Serif Pro',
'font-style' => 'normal',
'font-weight' => '200 900',
'font-stretch' => 'normal',
'src' => 'https://example.com/assets/fonts/source-serif-pro/SourceSerif4Variable-Roman.ttf.woff2',
'font-display' => 'fallback',
),
array(
'provider' => 'local',
'font-family' => 'Source Serif Pro',
'font-style' => 'italic',
'font-weight' => '200 900',
'font-stretch' => 'normal',
'src' => 'https://example.com/assets/fonts/source-serif-pro/SourceSerif4Variable-Italic.ttf.woff2',
'font-display' => 'fallback',
),
)
New structure:
array(
'source-serif-pro' => array(
array(
'provider' => 'local',
'font-style' => 'normal',
'font-weight' => '200 900',
'font-stretch' => 'normal',
'src' => 'https://example.com/assets/fonts/source-serif-pro/SourceSerif4Variable-Roman.ttf.woff2',
'font-display' => 'fallback',
),
array(
'provider' => 'local',
'font-style' => 'italic',
'font-weight' => '200 900',
'font-stretch' => 'normal',
'src' => 'https://example.com/assets/fonts/source-serif-pro/SourceSerif4Variable-Italic.ttf.woff2',
'font-display' => 'fallback',
),
),
)
I can see the benefits of grouping variations to their font family before passing it to this function. That said, it will have an impact on plugin authors who are already using the API.
With that in mind, @aristath @desrosj what do you both think?
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.
If the older format in theme.json
keeps working, then changing this will be fine 👍
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.
We could look for an associative array, and if associative keys are not present trigger a _doing_it_wrong()
, and then just move the font-family
value to the key.
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.
We could look for an associative array, and if associative keys are not present trigger a _doing_it_wrong(), and then just move the font-family value to the key.
I have a mock up of this and was considering it for a first phase migration. Not sure if this would be need though once merged into Core. But would help while still in experimental phase in Gutenberg.
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 looked at a dozen or so block themes in the directory and I couldn't find any that were using the current implementation.
However, my stance is usually that any time we change an API that is publicly released in a version of WordPress, we should assume it's being used in that way.
c4fd65f
to
e55bab4
Compare
ba4847a
to
1c4e7ea
Compare
Removes and gitignore composer.lock file Removes PHPUnit dep from composer.json
PHPCS: Exclude PHPUnit tests from file and class name sniffs (for Core parity)
defbd63
to
e571a86
Compare
Okay, this PR is 99% ready. Needs more testing and a thorough review. But the commit history is a mess. And it needs to be rebased against trunk. That's my next task > clean up the commit history and transform into atomic commits. |
Closing in favor of PR #43492. |
Closes #41481.
See PR #40556 for the Proof of Concept (PoC).
THIS PR IS NOT READY. It's in development.
What?
Changes the Webfonts API's architecture to use WordPress Core's Dependencies API.
TODO
Why?
... details will be coming when the PR is ready ....
How?
... details will be coming when the PR is ready ....
Testing Instructions
Screenshots or screencast
Dependencies
This PR requires the following PRs to be merged into
trunk
and thentrunk
merged into here: