Skip to content
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] Relocate which fonts to print into wp_print_fonts() #50151

Merged
merged 7 commits into from
May 8, 2023

Conversation

hellofromtonya
Copy link
Contributor

@hellofromtonya hellofromtonya commented Apr 27, 2023

Fixes #50140

What?

Relocates the decision making code about which fonts to print for the iframed editor out of the script-loader and into the wp_print_fonts() function.

Why?

When in the Site Editor, all registered fonts should be printed for user previewing and selection. Else, all enqueued fonts should be printed. This kind of decision making should be in the Fonts API, rather than externally in the script-loader.

How?

This PR places the decision making logic into wp_print_fonts().

How to identify the iframed editor assets function is invoking the printing?

This function needs to know if the request to print is coming from the iframed editor for decision making about which fonts to print. This is done by passing true to the first parameter of wp_prints_fonts().

Notes: true for $handles is not used by WP_Dependencies (including in wp_print_styles() and wp_print_scripts(). Using it avoids performance hits and BC concerns with the other strategies considered (expand the next section more more details).

Strategies considered

Approach 1: Adding a parameter to the function's signature

Pros:

  • straight-forward approach as the invoking code in the script-loader files sets it to true.
  • avoids the overhead of firing a hook.
  • avoids third-party hooking into this part of the code, i.e. a hook is available later in the call stack.
  • more performant than the other approaches.

Cons:

  • Deviates from wp_print_styles() and wp_print_scripts().
  • Adds a method parameter which must be maintained for BC once in WP Core.

Approach 2: Pass true to the first parameter as flag to indicate to populate the iframed editor handles.

Pros:

  • No additional function parameter is needed, meaning no future BC concerns for adding a parameter.
  • Unique flag: true is not used in wp_print_styles() or wp_print_scripts().
  • No performance hit.

Cons:

  • Could it cause confusion? 🤔

Approach 3: Add or use a hook.

Approach 3.1: Hook into the 'block_editor_settings_all' to modify the '__unstableResolvedAssets' setting.

In WP Core, the call stack is this:

_wp_get_iframed_editor_assets()
invokes
_wp_get_iframed_editor_assets()
which will invoke
wp_print_fonts()

There is a filter after this code called 'block_editor_settings_all'.

Gutenberg uses this approach to modify the settings for the upcoming release.

Pros:

  • No extra hook or function parameter to maintain for BC.

Cons:

  • Once in Core, the code would be separate from _wp_get_iframed_editor_assets(), which would make maintaining more complex.
  • Contributors would need to stay aware of changes in _wp_get_iframed_editor_assets() that could require changes within wp_print_fonts() of which setting or subsetting to modify. (Conversely if invoking directly within _wp_get_iframed_editor_assets() all knowledge is contained in one place for the iframed editor assets.)
  • Performance hit: adding and firing a hooked callback has a performance cost.
Approach 3.2: Add a hook in _wp_get_iframed_editor_assets().

Pros:

  • Wires internal and external iframed editor asset functionality together (vs using a hook later in the call stack).

Cons:

  • Adds another hook that must be maintained forever due to BC.
  • Performance hit: firing a hook has a performance cost.

TODO

  • Relocate from 6.2 compat file.
  • Relocate from 6.3 compat file.
  • Explore options of how to tell if the request is from the iframed editor or not.
  • Add tests to validate.

Testing Instructions

Visually Test:

Set up on your test site:

  1. Activate the Gutenberg plugin.
  2. Activate TT3 theme.

Before applying this PR:

  1. Go to the Site Editor > Styles > Typography.
  2. Using your browser's dev tools, search the HMTL for wp-fonts-local <style> element.
  3. Copying the internals of that element. You'll use this to compare after applying this PR.

After applying this PR:

  1. Go to the Site Editor > Styles > Typography.
  2. Using your browser's dev tools, search the HMTL for wp-fonts-local <style> element.
  3. Compare the styles to the before styles from above. They should match.

Running the automated tests

All tests should pass when running the PHPUnit tests:

npm run test:unit:php -- --filter Tests_Fonts_WpPrintFonts

@hellofromtonya hellofromtonya added [Type] Enhancement A suggestion for improvement. [Type] Code Quality Issues or PRs that relate to code quality [Feature] Fonts API labels Apr 27, 2023
@hellofromtonya hellofromtonya self-assigned this Apr 27, 2023
@WordPress WordPress deleted a comment from github-actions bot May 1, 2023
@hellofromtonya hellofromtonya force-pushed the try/move-printing-logic-to-wp_print_fonts branch from 5663329 to 6ce3620 Compare May 1, 2023 21:15
@hellofromtonya hellofromtonya marked this pull request as ready for review May 2, 2023 16:07
@hellofromtonya hellofromtonya force-pushed the try/move-printing-logic-to-wp_print_fonts branch from 1a9ae3f to cf9942a Compare May 2, 2023 16:12
@hellofromtonya hellofromtonya removed the request for review from spacedmonkey May 2, 2023 16:12
@hellofromtonya
Copy link
Contributor Author

Now that PR #50225 has been merged into trunk, I'll rebase this PR on top of it.

This simplifies the code as it removes the need to modify and then reset
the `done` and `queue` properties.
@hellofromtonya hellofromtonya force-pushed the try/move-printing-logic-to-wp_print_fonts branch from cf9942a to d95eb1c Compare May 2, 2023 20:25
Comment on lines 201 to 205
// Print all registered fonts for the iframed editor.
if ( true === $handles ) {
$handles = $registered;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this condition be moved above the if ( empty( $handles ) ) { check a few lines above? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good observation @aristath! Yes, I agree with you.

In looking further at this area of code, there's a tiny tiny micro-optimization opportunity which will benefit the front-end, i.e. when false then skip over these decision-making reassignment conditionals as they are unnecessary.

Changes done here fd7ce33

@hellofromtonya hellofromtonya force-pushed the try/move-printing-logic-to-wp_print_fonts branch from c1a255a to 338d4aa Compare May 3, 2023 14:30
Combines the empty() and true checks into a if/elseif structure.

For a tiny micro-optimization, wraps these checks within a not
equal to `false`.

Why?

When using the default (i.e. on the front-end and with classic themes):

* Skips running `empty()`.
* Skips reassigning `false` to `$handle`.

These skips gain a tiny tiny performance boost.
@hellofromtonya hellofromtonya force-pushed the try/move-printing-logic-to-wp_print_fonts branch from 338d4aa to fd7ce33 Compare May 3, 2023 14:49
Copy link
Contributor

@anton-vlasenko anton-vlasenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried to follow the testing steps, and after applying the patch I couldn't find the style#wp-fonts-local element.
Screenshot 2023-05-04 at 19 51 33

Printing `$handles` does not work (for some reason that needs to be investigated further). Overwriting
the queue and done properties does print and has been working since 6.2 alpha. This commit restores
the overwriting properties approach.
@hellofromtonya
Copy link
Contributor Author

@anton-vlasenko thank you for testing. You're right. It does not print within the Site Editor or other block editors (like Posts).

Why?
In investigating, there's something wrong within the Fonts API or WP_Dependencies when injecting $handles into do_items() inside of an ob_ circuit. Not sure yet of the root cause.

How I fixed it:
I've restored the overwriting of queue and done properties, like it was in the 6.2-compat file. In my testing, fonts are again being printed in the Site Editor.

Restoring that logic keeps the PR's scope focused on "relocating" the logic. A follow-up PR can come later for changing the approach to copying registered fonts to $handle (instead of overwriting properties).

Can you re-test please @anton-vlasenko ?

@hellofromtonya hellofromtonya added the Backport to Gutenberg Minor Release Pull request that needs to be backported to a Gutenberg minor release label May 8, 2023
@hellofromtonya hellofromtonya added this to the Gutenberg 15.7 milestone May 8, 2023
@github-actions
Copy link

github-actions bot commented May 8, 2023

Flaky tests detected in dfd8657.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4918768728
📝 Reported issues:

Copy link
Contributor

@anton-vlasenko anton-vlasenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've retested this PR after applying the changes in dfd8657, and it worked in my tests. The code makes sense, so I approve this PR.

@anton-vlasenko
Copy link
Contributor

Why? In investigating, there's something wrong within the Fonts API or WP_Dependencies when injecting $handles into do_items() inside of an ob_ circuit. Not sure yet of the root cause.

How I fixed it: I've restored the overwriting of queue and done properties, like it was in the 6.2-compat file. In my testing, fonts are again being printed in the Site Editor.

Restoring that logic keeps the PR's scope focused on "relocating" the logic. A follow-up PR can come later for changing the approach to copying registered fonts to $handle (instead of overwriting properties).

Thank you for the thorough explanation, @hellofromtonya!

@hellofromtonya
Copy link
Contributor Author

Thanks for retesting and approving the PR @anton-vlasenko!

@hellofromtonya
Copy link
Contributor Author

Cherry-pick for minor notes:

This PR requires #50225 to be cherry-picked first. Why? It uses code from PR #50225.

cc @bph

@hellofromtonya hellofromtonya merged commit fa1d3b0 into trunk May 8, 2023
@hellofromtonya hellofromtonya deleted the try/move-printing-logic-to-wp_print_fonts branch May 8, 2023 20:07
@autumnfjeld
Copy link

cc: @arthur791004

bph pushed a commit that referenced this pull request May 9, 2023
Moves decision-making logic for iframed editor from the compat script-loader files into the Fonts API.
@bph
Copy link
Contributor

bph commented May 9, 2023

I just cherry-picked this PR to the release/15.7 branch to get it included in the next release: 5682ad4

@bph bph removed the Backport to Gutenberg Minor Release Pull request that needs to be backported to a Gutenberg minor release label May 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Code Quality Issues or PRs that relate to code quality [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Fonts API] Relocate which fonts to print from script-loader into wp_print_fonts()
5 participants