webfonts handler: use public API instead of private one

[oandregal]

Substitute the call to a private API WP_Theme_JSON_Resolver::get_merged_data()->get_settings(); for the public API equivalent wp_get_global_settings().

Trac ticket https://core.trac.wordpress.org/ticket/59028

## What

This substitutes the call to a private API WP_Theme_JSON_Resolver::get_merged_data()->get_settings(); for the public API equivalent wp_get_global_settings().

## Why

We should use our public APIs when possible.

## How to test

Verify all tests pass.

@oandregal all of this code, i.e. _wp_theme_json_webfonts_handler(), is temporary. Font management is big feature in 6.4. Thus, all of this code will be replaced during 6.4 alpha, i.e. replaced by the new Font Face (in Gutenberg).

I'm wondering:

• Should this change be done in the ​Font Face Resolver?

• Should this PR be committed into Core knowing it'll be replaced soon?

When will it replaced?
As soon as the Fonts Library backend code is released in Gutenberg, then both the Font Face and Fonts Library PHP code will be merged into Core. I expect this will happen in the next few weeks.

Should this change be done in the ​Font Face Resolver?

Yeah, we should. I was planning to do a pass in Gutenberg for the same thing later on.

Should this PR be committed into Core knowing it'll be replaced soon?

I believe so. It's a minimal change. Also, in general, temporary code lives much longer than we expect it to do.

Font feature has been pushed many times. I say merge this small change, it can't hurt it is removed later.

@hellofromtonya what do you think? I lean towards going ahead with this, given the minimal change and how low impact it is. I am not happy sending even more work towards you! I'm finding it a bit hard to find reviewers that can quickly approve that minimal a change. Though, it is important to me that we use our own APIs the right way.

I asked the question because committing code that will be removed in the same release cycle seems unnecessary. That said, if for some reason the font management feature planned for 6.4 (the Fonts Library and the code which will replace this temporary stopgap code) does not ship in 6.4, then the changes proposed in this PR can go in.

I leave the decision of when to commit this change to you @oandregal, i.e. immediately or wait to see if the font management feature goes into 6.4.

As for the change itself, I trust your judgement and expertise on using wp_get_global_settings() in place of using the chain of objects.

Should this change be done in the ​Font Face Resolver?

I've prepared a gutenberg PR for this as well ​https://github.com/WordPress/gutenberg/pull/53805

I asked the question because committing code that will be removed in the same release cycle seems unnecessary. That said, if for some reason the font management feature planned for 6.4 (the Fonts Library and the code which will replace this temporary stopgap code) does not ship in 6.4, then the changes proposed in this PR can go in.

I'm fine waiting until before the beta, if that's helpful. I added a reminder in my calendar to get back to this in September 18th (later my availability is limited). I still need an approval to merge :)

[hellofromTonya]

Thank you @oandregal for opening this ticket. The stopgap code is being deprecated in #59165 which is introducing Font Face into Core to replace it. As it's being deprecated, I'll close this ticket as wontfix given that the code will no longer be used in Core and it's highly unlikely extenders are using it.

The follow-up Gutenberg PR ​https://github.com/WordPress/gutenberg/pull/53805 that modifies the WP_Font_Face_Resolver with the same change will be part of the code that is introduced in #59165.

Thank you for your contribution :)

The Trac ticket has been closed as wontfix as the stopgap code is being deprecated and replaced by Font Face in https://core.trac.wordpress.org/ticket/59165. Thank you all for your contributions!

[oandregal]

That's good progress, thanks, Tonya.

I'll keep an eye on that ticket, in case I can help. If the old code is not removed from core, I'd still like replacing the direct call to the object – even if it doesn't run at all, others can still see the code and copy the pattern.