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.

[peterwilsoncc]

@creativecoder Is there a way for font plugins to work without a post object? Something to allow developers to hook straight in to the font library rather than via a font collection?

---

I think this change would change fonts from a second class object (ie, one that relies on databse content) to a first class object (ie, one that is loaded as part of bootstrapping). This is fine but the following would need to be considered:

The big risks I see are:

• how to handle the change in object status & migration from one to the other, specifically for deploy scripts using rsync to delete files that aren't in a repo & our old friend immutable file systems -- the former being far more common that the latter.
• performance: what's the impact of reading the various files. The Open Sans variable webfont comes with up to 20 files on Google Fonts (per CSS file)
• performance: how to handle to removal of a font file with regard to global styles
• the upgrade process: like plugins, fonts can be improved over time -- improved ligatures -- so the API would need to manage that.
• If migrated, how to handle the multisite sub-folders, do fonts become available across all sites.

In terms of value, I think this is complicated.

The existing approach for committed fonts is to place them in the theme folder. A benefit this provides is that a server can have multiple sets of fonts available for different themes. A site owner can then use specific fonts via the upload tab, this allows WordPress to use lower capabilities than required for installing plugins.

A switch to first class objects would require a permission structure much closer to the installation of themes and plugins and potentially reducing the reach of the font library feature.

[creativecoder]

Is there a way for font plugins to work without a post object? Something to allow developers to hook straight in to the font library rather than via a font collection?

@peterwilsoncc Not currently. Being largely based on how uploads/attachments work, the server-side portion of the font library (mainly the REST API endpoints) is dependent on using font family and font face posts to store font settings and keep a reference to the files.

One thing to keep in mind is that how a font is defined for the font library is directly tied to Global Styles and theme.json. The typography.settings.fontFamilies.fontFace items in theme.json need both a file reference and metadata that determine the css properties used for @font-face output. While common properties could be inferred from the font file (like style and weight), I'm not sure if we can parse all available properties from the file itself. Properties like sizeAdjust and fontVariationSettings` may not be inherent in the font file, but rather settings that control how the font is displayed by the browser--but I'm not 100% certain on this.

So that leaves us with a couple of potential approaches:

• Parse font-files directly and apply fontFace support for those properties that can be inferred from the font file
• Add a way to define metadata that sits aside the font file (something like font-face.json)

These aren't exclusive, we could implement both. Both seem possible, though definitely not simple, and come with significant performance and security concerns, as you point out.

[peterwilsoncc]

I've been considering some potential approaches to this:

• this converts fonts to be more akin to plugins and themes than uploads (no associated post object)
• retaining the current directory (uploads/fonts) won't work for this as the uploads directory is very rarely open to commit due to being in the gitignore file
• as theme/plugin like objects, fonts will need to be available to all multisites so the uploads/sites/[id] directory structure is no longer appropriate. sitename.example.org vs sitename.staging.example.org may have different site IDs

For multisite, I think the following would need to be considered:

• does the site super admin enable fonts for individual sub sites (similar to enabling themes)
• does the site super admin enable the "font menu" (or whatever) and allow individual sub sites access to all fonts (similar to plugins)

As this missed WP 6.6, is it been planned for WP 6.7?