-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Font Library: Handling for fonts that exist in the /fonts
directory but have not been added in the Font Library
#59102
Comments
Related Slack thread: https://wordpress.slack.com/archives/C02QB2JS7/p1707937998405009 |
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 |
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 Presently, at Pantheon, I've adapted our mu-plugin to change the default path for fonts to be uploaded to back to the 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? |
per WordPress/gutenberg#59102 (comment) it seems like fonts are more likely to be treated like media files, in which case it would be undesirable to commit them to the repository, so we're removing our override. our behavior can still be overridden by removing or changing the font_dir filter at a priority higher than 9 (default is 10).
* remove the filter to override our customization per WordPress/gutenberg#59102 (comment) it seems like fonts are more likely to be treated like media files, in which case it would be undesirable to commit them to the repository, so we're removing our override. our behavior can still be overridden by removing or changing the font_dir filter at a priority higher than 9 (default is 10). * update tests
Even though WP 6.5 will keep fonts in Fonts are like Unlike for example a logo media item, that understandably varies from site to site, the 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.
@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 |
@justlevine (and others following this issue!) you can already include fonts in a theme using the font files and the associated 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 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:
Note This is all premised on #60354 being reverted, and fonts (re)located to |
@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:
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. |
@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 So that leaves us with a couple of potential approaches:
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. |
I've been considering some potential approaches to this:
For multisite, I think the following would need to be considered:
As this missed WP 6.6, is it been planned for WP 6.7? |
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 intowp-content/fonts/
, not using thefont_dir
filter to change that path or.gitignore
'ing thewp-content/fonts/
directory), my fonts are committed to source control between environments.If I deploy my code changes (e.g. from
develop
->stage
orprod
), including any fonts that were added indevelop
, the font files will get deployed to my staging/live environments, but WordPress does not know about them. Let's assume mydevelop
environment is messy. I don't want to database clone fromdevelop
toprod
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.
The text was updated successfully, but these errors were encountered: