Peter Wilson 10:51 pm on March 21, 2024
Tags: 6-5 ( 76 ), dev-note ( 18 ), dev-notes ( 540 ), dev-notes-6.5 ( 15 )

Font Library update: storage of font files

This post has been superseded by the post WordPress 6.5 release delayed 1 week, in which it’s announced fonts will be uploaded to the fonts sub-directory of the uploads folder.

The Font Library, a new feature of WordPress 6.5, will allow users of blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor themes to upload and customize their site’s fonts. You can learn about the full set of Font Library features in the #dev-note.

As fonts are a new first-class object, there has been some discussion around where to store the associated files while accounting for different file systems used by WordPress sites. The particular challenge has been for file systems that do not allow for the writing of files outside the uploads directory (See Gutenberg#59417 and Gutenberg#59699).

To account for such file systems, it was originally decided to natively fallback to the uploads directory natively in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

Revised approach to font file storage

Exploratory work on supporting a fallback directory natively has demonstrated that this approach would lead to a high risk of bugs. Therefore, the original decision is being modified and the new approach will be:

WordPress Core will by default only attempt to store font files in the wp-content/fonts directory,
For file systems unable to write to or persistently store files in the new directory it is recommended to install the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Fonts to Uploads to store the files in the under existing uploads directory, in wp-content/uploads/fonts
Developers wishing to modify the directory without using a plugin can use the font_dir filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. documented in the announcement post.

Props @mmaattiiaass and other contributors for working on the exploratory pull request.

Thank you @desrosj, @priethor, @chanthaboune and @jorbin for contributing to and reviewing this post.

#6-5, #dev-notes, #dev-notes-6-5

Ryan McCue 11:08 pm on March 21, 2024

I think this is a significant mistake that deviates from WordPress’ coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. philosophies, the existing technical infrastructure, and the stated requirements and plan for shipping in 6.5.

Core evolves, and I understand the motivation behind introducing a new directory. While I personally don’t agree with it (font files are attached to database data, so the existing uploads model should apply), the compromise plan achieved a decent balance between the philosophical arguments and the technical limitations.

By removing a key aspect of the compromise plan, it undermines the entire plan, and means we are fundamentally shipping something we know is broken with 6.5.

Up until now, there have been two classes of file in WordPress: the codebase, and data. Data lives in the uploads directory, is controlled by end-users, and there’s a wide expectation that users are able to manage this via the CMS. The codebase comprises the rest of the files, is controlled by developers, and there’s clear ways to control this programmatically (WP also helpfully provides tools where end-users are developers too). Controls are available for the data storage location (wp_upload_dir) and to lock down the codebase (DISALLOW_FILE_MODS).

For reasons that still aren’t clear to me, fonts ignore both of these controls. This makes them a new third type of file. While I don’t understand why this would be the case, I’m less concerned about that part of the details.

What does concern me is that the clearly articulated and communicated compromise plan has been changed in a way that throws away the “compromise” part entirely. I don’t understand why the discussion, debate, and decision on the compromise would be made if it’s being ignored.

Additionally, this decision has been made three release candidates in, providing inadequate time for testing either the now-broken behaviour we plan on shipping with, or the fallback if it does end up getting merged.

As Josepha clearly stated in the plan, the fallback “[ensures] we stay true to our project philosophy of designing for the majority while still making the feature available to anyone out of the box without extra steps from the user”.

What has changed since this plan that makes deviating from this philosophy worth it?
- Thomas Kräftner 9:57 am on March 22, 2024
  
  1000% agree. This will cause so much trouble with a lot of setups.
  E.g. all setups that drop anything but a symlinked uploads directory on each deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors..
- Matias Benedetto 2:53 pm on March 22, 2024
  
  (DISALLOW_FILE_MODS).
  For reasons that still aren’t clear to me, fonts ignore both of these controls.
  
  To add context, the reasons why this DISALLOW_FILE_MODS was ignored were discussed here:
  
  https://github.com/WordPress/gutenberg/issues/55280
  
  https://github.com/WordPress/gutenberg/pull/5929
- Nico 9:14 am on March 24, 2024
  
  Completely agree about the fonts dir, especially just rudely ignoring DISALLOW_FILE_MODS.
  
  Last I read about this, they said it will auto fallback to uploads. Did this check for DISALLOW_FILE_MODS in the past? Or did it auto fallback just if files are not writable in wp-content/fonts/?
  
  Now it seems they made it even worse and there is no fallback anymore, and you need to download an extra pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or set up your own filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to move them to uploads.
Andrei Lupu 11:38 pm on March 21, 2024

So basically the decision of moving uploadable fonts outside of the uploadable folder is already proven problematic even before releasing with partial testing.

And TBH `wp-content/uploads/fonts` path was semantically better in the first place.
- Matias Benedetto 6:59 pm on March 22, 2024
```
the decision of moving uploadable fonts outside of the uploadable folder is already proven problematic even before releasing
```
  From my point of view, this is inaccurate.
  
  I wasn’t involved in the conversation about adding the fallback to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s codebase, and now the decision about whether to do so would be more of a problem than a solution. I don’t have a strong feeling about one path or the other.
  
  I can speak about the technical aspects of the fallback because I’ve been involved in some of the proposals around adding a fallback path value to the core codebase.
  
  I don’t think that the complexity is about setting another folder to host the fonts because that’s simple just by filtering ‘font_dir’ as any other WordPress filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. that allows users to customize values.
  
  The complexity lies in the fact that, as far as I know, there’s no other ‘fallback path’ value in the core’s codebase, and adding and testing it reliably would be costly in terms of time and complexity, and, probably, it doesn’t be worth because the use of a filter or a plugin is simple a reliable for host admins that want to set a path different to the default one.
  - Andrei Lupu 2:36 am on March 23, 2024
    
    I don’t have a strong feeling about one path or the other.
    
    IMO the problem is that many contributors joined the conversation with this premise, ignoring that one path is way more complex then another which now is proven to be problematic (even predicted in github discussions)
    
    Having to use a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. or a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for simply using a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. feature feels like we are moving away from the WordPress core values which is:
    
    The basic WordPress software is simple and predictable, offering powerful features for growth and success.
Christopher 5:22 am on March 22, 2024

What about multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site? Where the fonts are stored?
- Jan Thiel 7:49 am on March 22, 2024
  
  @peterwilsoncc Same question here. Haven’t found a single word about the handling of the font files within a Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site environment.
  Are font files shared between sites? Are they installed and managed from the networknetwork (versus site, blog) adminadmin (and super admin)? Or are they stored on a per site base like the uploads?
  
  I totally agree with @rmccue the current set of changing decisions that late in the 6.5 release cycle is highly frustrating and irritating. From an infrastructure providers (aka “Hoster” / SaaS provider) perspective there are many question marks at the moment. The current folder structure of WordPress is used for many caching and other access protections rules in our case.
  If fonts are “first class citizens” they have to be handled like Themes and Plugins. Centrally managed, installed and deleted. But that does not fit to what a single site user expects from a Font Library. Each site has different font requirements. The intersection is highly limited which makes fonts more or less nearly always site specific.
  The current WordPress folder structure supports the management @rmccue describes. It is mandatory that we can continue to rely on that. “User generated content” / Site specific content has to remain in the single sites upload directory.
  
  I know we could simply try that out, but missing that essential part in any communication makes me wonder. And worry…
- Matias Benedetto 3:14 pm on March 22, 2024
  What about multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site? Where the fonts are stored?
  
  The multi-site font assets are saved in :
```
/wp-content/fonts/<site-id>/a-font-file.ttf
```
  - Matias Benedetto 3:15 pm on March 22, 2024
    Correcting myself, the path is:
    
    /wp-content/fonts/sites/<site-id>/a-font-file.ttf
    - Chris Reynolds 5:51 pm on March 22, 2024
      
      Would I be correct in assuming that if you were filtering the font_dir to /wp-content/uploads/fonts that, on multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, your path would be
      
      /wp-content/uploads/fonts/<site-id>/a-font-file.ttf
      
      ?
      - Matias Benedetto 6:34 pm on March 22, 2024
        
        Filtering ‘font_dir’ as in this example the fonts are written in the following path:
        
        /wp-content/uploads/sites/<site-id>/fonts/
        
        Chris Reynolds 6:40 pm on March 22, 2024
        
        👍 Great, thanks for clearing that up. That makes sense. I haven’t had a chance to test this path.
        
        Christopher 6:20 am on March 23, 2024
        
        Shouldn’t that be the default behavior? Why create another tree of subfolders for the fonts when there’s already a folder for each subsite?
David Levine 6:23 am on March 22, 2024

I wholly agree with everything @rmccue wrote.
John Blackbourn 2:17 pm on March 22, 2024

I agree with the comments above. It appears that in an attempt to force fonts to fit into a certain shaped box we’ve ended up with a feature that will be inconsistent on some sites and fully broken on others without either a third party pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (which isn’t shipping in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. because of the “high risk of bugs”) or custom code in place to change the font file location to one which is writable.

What we’re going to end up with is the font manager behaving in three different ways:

1. Fonts are stored as the development team would like them to be in `wp-content/fonts`.
2. Fonts are stored in `wp-content/uploads/fonts` on platforms where this is needed (with this disproportionately being the case on high value hosts and high value installations such as enterprise publishers).
3. The font manager feature doesn’t work at all because `wp-content/fonts` isn’t writable.

(See the discussion on https://github.com/WordPress/gutenberg/issues/59417 for background if you’ve not been following this problem.)

I think that an inconsistent location for fonts is worse than trying to force what the development team think is the ideal location but having to put into place fallbacks. On sites that cannot support the preferred location, as Pete wrote above, implementing a fallback is proving significantly more difficult than anticipated.

I was never entirely convinced by the proposal that a font can and should be a new first-class object type in WordPress. A font file on its own does nothing, it needs to be backed by a row in the `wp_posts` table and it needs to exist once for each separate site on a Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site networknetwork (versus site, blog), which means it acts nothing like other entities such as plugins or themes. I think this needs to be revisited yet again and my suggestion is to either switch back to storing fonts in `wp-content/uploads/fonts` in order to regain consistency and reliability, or we need to question whether we’re now just trying to force the font feature into 6.5 due to the understandable frustration of the development team who want to see it shipped.
- Matias Benedetto 3:37 pm on March 22, 2024
  
  On sites that cannot support the preferred location, as Pete wrote above, implementing a fallback is proving significantly more difficult than anticipated.
  
  I’ve been involved in the code proposals to add the fallback, and I think the difficulty lies in adding it to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s codebase. This is partly because, as far as I know, no other path has a built-in fallback path in the core’s codebase.
  
  On the other hand, if a site/hosting adminadmin (and super admin) wants to change the folder’s location, it’s pretty straightforward to use the `font_dir` filter to change the path to /wp-content/uploads/fonts or any other path wanted.
  - Nico 9:22 am on March 24, 2024
    
    It does not matter how straight forward it is to use some filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., the point is, it should be even be necessary to use any filter for such a basic functionality.
    
    And actually I do not consider this very straight forward. Other simple filters just need a __return_true or something that are basically switches.
Matias Benedetto 2:49 pm on March 22, 2024
👋 Hi, just in case it helps: the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to move is just a ‘one-click’ solution, but the filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to change the location to uploads is as simple as adding this filter:
```
function filter_default_font_directory( $font_directory ) {
	$upload_dir = wp_get_upload_dir();

	$font_directory = array(
		'path'    => untrailingslashit( $upload_dir['basedir'] ) . '/fonts',
		'url'     => untrailingslashit( $upload_dir['baseurl'] ) . '/fonts',
		'subdir'  => '',
		'basedir' => untrailingslashit( $upload_dir['basedir'] ) . '/fonts',
		'baseurl' => untrailingslashit( $upload_dir['baseurl'] ) . '/fonts',
		'error'   => false,
	);

	return $font_directory;
}

add_filter( 'font_dir', 'filter_default_font_directory' );
```
burnuser 9:26 am on March 23, 2024

Apart from the complexity, one very important point isn’t mentioned anyway: reliability of backup and – in case of emergency – moving the backup to another hoster:

1. If the used backup (pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party) doesn’t cover the fonts directory, fonts aren’t saved (and, in case, moved). Which means also: fonts are not recovered => Website layout is broken!
(“uploads” directory is a default in any backup solution, “wp-content” as a whole is not!)

2. If hoster A (= source of website-moving) supports a writeable “wp-content” directory, but hoster B (= target of website-moving) only allows “uploads” to write in, fonts – also covered in a backup – can not be recovered => Website layout is broken!

Any serious website must be able to rely on backups and recovery when needed, on same or other host.
So, the only possible (because in any case correct working) solution in real world is using the “uploads” directory.
Which means, the new – in its functions great – font feature in WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. can only be used with the additional plugin “Fonts to Uploads”.

And this plugin must be installed and activated before the first font is manually added, because it only works for fonts added afterwards. Otherwise you get two different saving locations (with the above stated problems of fonts in “wp-content”).

How can anyone explain this whole mess to simple users?

There is only one everywhere working solution and it is very simple:
Make “uploads” to the one and only fonts directory and forget about additional must use plugins and similar unnecessary fallbacks or repair solutions for an artificial self created problem!
- Jan Thiel 9:31 am on March 23, 2024
  
  Excellent point!
  WordPress loses portability with this (mess). Besides all the other mentioned points that’s a show stopper for itself.
Earle Davies 2:53 pm on March 23, 2024

I agree with all of the stated objections above to implementing this feature as it’s programmed. The suggestion that a brand new feature for WordPress needs to be launched alongside a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to fix the poor consequences of using it says everything it needs to. One of the counter points made in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. was there is a precedent because ‘we have a fallback plugin like classic editor’….. What?! Classic editor is not a long term supported thing it’s a hack to get people who can’t upgrade to GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. It’s not something we should be using as proof of how we should launch a new feature. It should be a shining example of how we missed the boat on backward compatibility and a seamless upgrade path for our users when releasing Gutenberg. This feature does’t release Fonts as a ‘first class citizen’. It puts fonts as some weird hackedhacked together middle ground where it’s half in the db, half in a file storage system no reputable host will support out of the box.
Andrew Ozz 12:00 am on March 27, 2024

It seems that many (or even most?) of the comments here are somewhat misguided, or contain misinformation.

The most important part of this misinformation is that “Fonts are uploads”. This is wrong.

Unlike images and other user supplied files fonts are downloaded and installed by WP just like themes and plugins. True, they can also be uploaded by the users, just like themes and plugins, but in the majority of cases they would probably be downloaded by WP, again just like themes and plugins. If you don’t believe me, please test by yourself! 🙂

The other “unproven assumption” is that storing fonts in wp-content/uploads/fonts would cause less bugs and errors. This is, again, a misconception as that location exposes fonts to all the “Media Library” type plugins. And since this is mostly untested, it is unknown how many users may be affected.

In that terms it is likely that storing fonts in wp-content/uploads/fonts would cause a lot of errors and prevent lot of WordPress users from being able to use this new feature. Seems that it can be a much larger number of users than if fonts are stored in wp-content/fonts. In addition the latter location has been tested for some time and the only affected parties are not the WP users, but few hosts.

So changing the location for fonts seems to be more of a “hosts vs. WP users” decision, with wp-content/uploads/fonts benefiting few hosting companies while wp-content/fonts benefiting a certain amount of WP users.
- Aaron Jorbin 3:50 am on March 28, 2024
  
  To avoid fragmented conversation, I just want to note that a reply was posted on https://make.wordpress.org/core/2024/03/25/wordpress-6-5-release-delayed-1-week/#comment-46401
Jan Thiel 7:58 am on March 28, 2024

Following @jorbin I added my reply as well here:
https://make.wordpress.org/core/2024/03/25/wordpress-6-5-release-delayed-1-week/#comment-46403
donrich 4:08 pm on June 26, 2024

Recently I moved my site to another domain… I used Interconnectit tool to replace old domain with new one.
Even tho, the font url didn’t updated.
Then I used Better Search Replace pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and didn’t find the font url.
Where is the font url stored in database? Or where can I change it?
- Sarah Norris 11:11 am on June 27, 2024
  Hi @r2kjet. The font URLs are stored in the `wp_posts` table in the `post_content` of the post for the corresponding font face. The post_type for these posts is `wp_font_face`.
  
  Here’s an example from one of my test sites:
```
{"src":"http:\/\/local-test-site.local\/wp-content\/uploads\/fonts\/RrQBbpJx9zZ3IXTBOASKp5gJAetBdaihcjbpD3UZcr7xbYw.woff2","fontWeight":"400","fontStyle":"normal","fontFamily":"\"Alumni Sans Inline One\"","preview":"https:\/\/s.w.org\/images\/fonts\/17.7\/previews\/alumni-sans-inline-one\/alumni-sans-inline-one-400-normal.svg"}
```
  I’m unsure why you couldn’t find the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org with those plugins – I’m wondering if it’s because the URL is stored with escaped slashes.

Comments are closed.

Welcome!

Communication

Font Library update: storage of font files

Revised approach to font file storage

Welcome!

Communication

Revised approach to font file storage

Share this: