Font Manager uses incorrect URLs on multisite

[peterwilsoncc]

Description

The font library manager attempts to load fonts using incorrect URLs in the font-manager when using Multisite in sub-directory mode.

In the console when I open the font manager model the Caro and Inter fonts attempt to load from the following URLs which throw 404 errors:

• http://gb-dev.local/two/wp-admin/undefined/wp-content/themes/twentytwentyfour/assets/fonts/cardo/cardo_normal_400.woff2
• http://gb-dev.local/two/wp-admin/undefined/wp-content/themes/twentytwentyfour/assets/fonts/inter/Inter-VariableFont_slnt,wght.woff2

Elsewhere in the site editor they appear to load from the correct URLs

WordPress installed in a sub-directory will also need to be tested.

Step-by-step reproduction instructions

Edit: Creating a sub-site in not necessary, the issue occurs on the main site too.

1. Configure Multisite in sub-directory mode
2. Create a sub-site /two/
3. Visit host/two/wp-admin/site-editor.php?canvas=edit
4. Open the browser's developer tools, clear the console.
5. Open Styles > Typography > Manage Fonts
6. Observe the 404 errors in your browsers console or network tab

Screenshots, screen recording, code snippet

Environment info

• WordPress 6.4
• Gutenberg trunk @ 4d5fd5a

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[t-hamano]

I was also able to reproduce this problem. A DOM exception error is occurring here, so there might be some problem with the loadFontFaceInBrowser() function.

[peterwilsoncc]

Thanks for the pointer @t-hamano, I worked backwards to find the source

It appears there are assumptions about the theme URL being made in this code that are incorrect

gutenberg/packages/edit-site/src/components/global-styles/font-library-modal/context.js

Lines 172 to 173 in 4d5fd5a

	const themeUrl =
	site?.url + '/wp-content/themes/' + currentTheme?.stylesheet;

The WP_CONTENT_DIR and WP_CONTENT_URL constants can be used to set the content directories to be pretty much anything so site.url can't be used to get a predictable result.

The JavaScript equivalents of get_stylesheet_directory_uri() and get_stylesheet_directory_uri() will need to be used for this purpose. if the data is not available in the theme's rest controller then the data will need to be added in another manner.

[peterwilsoncc]

I've confirmed this is happening on Single Site installs with custom directory set ups.

[swissspidy]

Hardcoding URLs like that is definitely incorrect and needs to be addressed

[matiasbenedetto]

Here's a potential fix for this issue: #59421