webfonts handler: use wp_get_global_settings instead of private API

[oandregal]

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.

[hellofromtonya]

@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.

[oandregal]

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.

[spacedmonkey]

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

[oandregal]

@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.

[hellofromtonya]

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.

[oandregal]

Should this change be done in the Font Face Resolver?

I've prepared a gutenberg PR for this as well WordPress/gutenberg#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]

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!