Font Library: Handling for fonts that exist in the /fonts directory but have not been added in the Font Library

[jazzsequence]

What problem does this address?

If I have a site that uses multiple development environments (e.g. develop, stage, prod), and I am using the default handling of fonts (e.g. installed directly into wp-content/fonts/, not using the font_dir filter to change that path or .gitignore'ing the wp-content/fonts/ directory), my fonts are committed to source control between environments.

If I deploy my code changes (e.g. from develop -> stage or prod), including any fonts that were added in develop, the font files will get deployed to my staging/live environments, but WordPress does not know about them. Let's assume my develop environment is messy. I don't want to database clone from develop to prod to "install" the fonts, so the only thing I can do is reupload the already uploaded fonts. When I do this, I am given an error that the fonts already exist, but I can now use the font because the post type is created.

#54226 would address this partially assuming I could export fonts only from my develop environment. Currently, doing this results in an unrecoverable error in the Site Editor that's only able to be solved by restoring a database backup, but this is still a sub-optimal process for handling fonts that already exist in the filesystem.

What is your proposed solution?

The most user-friendly way of handling this would be to scan the font_dir for fonts when the Font Library is opened and automatically add (but not activate) any fonts that are read that are not currently listed in the Library. Possibly an update or sync files button could be listed at the bottom of the Font Library to prompt a manual sync.

Ultimately, any means of WordPress "knowing" or "seeing" that the fonts exist in some form would be preferable, even if that meant a manual process to "install" the uploaded font.

[jazzsequence]

Related Slack thread: https://wordpress.slack.com/archives/C02QB2JS7/p1707937998405009

[matiasbenedetto]

Hi 👋

I think what you describe is the standard WordPress behavior. It works in the same way on the Media Library. If you manually added image assets to the uploads folder of your server, WordPress doesn't know about them and they won't be featured in the Media Library. The opposite is also true, if you have the Media posts created but you manually deleted the files from your server uploads folder the Media Library will link a missing image that won't render because of the missing asset. I don't think we should change that behavior.

This issue seems to be closely related this one: #58375

[jazzsequence]

Hey @matiasbenedetto 👋

What you say is true if you consider fonts to be adjacent to media files. It seems in some cases, and in some conversations, it's unclear if fonts are more like media files or more like themes and plugins. In many conversations I've had about the feature outside of WordPress core channels (but also within as well), there is some sentiment that some times or some people might consider fonts to be more like plugins or themes -- e.g. an asset that is committed and a fundamental part of your site repository, that gets installed, activated, etc -- than they are like a replaceable media file that could even be written to an external storage bucket.

The decision to move the /fonts directory out of wp-content/uploads/ and into the root wp-content/ directory seems to confirm this idea that "fonts aren't like media files, they are more like themes and plugins."

Presently, at Pantheon, I've adapted our mu-plugin to change the default path for fonts to be uploaded to back to the uploads folder, because our filesystem is not writeable outside that directory. But I've left an option in to back that change out and restore the WordPress core behavior if users wanted to commit their fonts to the repository and maintain it as a fundamental part of their site. What I'm hearing is that fonts (in this context) are not a fundamental part of the site, they are a semi-disposable asset, and that we would have no reason to give users the option to restore the core behavior in storing fonts in wp-content.

Since the earliest introduction of this feature, I've been unclear on whether fonts were more like media files or more like themes/plugins, and the gist of what I've gathered is "well, kinda both." But if there's no way to support the more like themes/plugins side, then they are firmly in the more like media files camp. Does that make sense?

[justlevine]

The decision to move the /fonts directory out of wp-content/uploads/ and into the root wp-content/ directory seems to confirm this idea that "fonts aren't like media files, they are more like themes and plugins."

Even though WP 6.5 will keep fonts in /uploads for now, I wanted to elaborate on this for when the time comes to relocate this or create other top-level wp-content types.

Fonts are like themes and plugins in that they are essentially static assets with a single source of truth.

Unlike for example a logo media item, that understandably varies from site to site, the Open Sans font is the same Open Sans font across every site it is used. Sure, different sites might be using different versions of a font, no different than plugins and themes.

Allowing fonts to be handled like themes/plugins (autoregistered + programmatic activation) would be a huge boon for agencies, enterprises, multisite, and multi-env builds - all use cases where the inability to easily sync database changes is one of the largest and longest-running sources of friction, as well as for devOps purists who want to git-commit as many changes as possible, and even support WP-to-WP migrations as part of the Data Liberation Project.

If you manually added image assets to the uploads folder of your server, WordPress doesn't know about them and they won't be featured in the Media Library. The opposite is also true[...] I don't think we should change that behavior.

@matiasbenedetto plugins/themes behave the same way, and I'm not seeing a clear reason why Fonts can't act the same. An autodiscoverable global registry at wp-content/fonts, that can be activated/deactivated per site, falling back to the system default if a font is not activated, or doesn't exist.

[creativecoder]

Allowing fonts to be handled like themes/plugins (autoregistered + programmatic activation) would be a huge boon for agencies, enterprises, multisite, and multi-env builds

@justlevine (and others following this issue!) you can already include fonts in a theme using the font files and the associated fontFamilies and fontFace properties in theme.json, which can be committed to version control and should be portable across environments.

What specific use cases are you thinking of for font portability that aren't covered by themes? I think it would help to have real examples in mind for looking at how we might address this.

[justlevine]

@creativecoder

What specific use cases are you thinking of for font portability that aren't covered by themes? I think it would help to have real examples in mind for looking at how we might address this.

Assumedly, it's all the same use cases that justified a global Fonts Manager in addition to handling those registered by theme.json.

Whether it's because the client is using Global Styles to override the theme-registered fonts currently, or future improvements for multisite (why have multiple copies of the same font, just because the themes are different) or exposure in a plugin API doesnt really matter; if for whatever reason a site is using a font, we'd ideally be able to track it in vcs like other static, versionable assets.

This would help us with:

• Better handle multiple environments (staging, develop), since it's one less thing we need to worry about using production as the source of truth.
• Better handling of WP-to-WP migrations, since font availability can be handled just by uploading the wp-content/fonts folder.
• Better font version updates, since they're centrally managed they only need to be versioned once; similarly, better programmatic testing/scaffolding (e.g. visual regression, theme compatibility testing).
• More intuitive DX: Fonts manually upload from backend do not show in frontend #60420 is a much more common assumption when fonts are in wp-content/fonts instead of wp-content/uploads/fonts.

Note

This is all premised on #60354 being reverted, and fonts (re)located to wp-content/fonts instead of nested in uploads.