Font Library: Fonts still listed as installed after they are manually deleted via FTP or by other means

[afercia]

Description

Users can delete, rename, move, files via FTP. While one could argue why users would ever want to delete font files via FTP the answer is that the will because it is possible to do it. See the Murphy's law in its original formulation:

If there are two or more ways to do something and one of those results in a catastrophe, then someone will do it that way.

Files may get corrupted as well because of hosting hiccups or because of any other reason.

The Font Library doesn't appear to handle these cases and for example still lists fonts as 'installed' even though the font files doesn't exist any longer. Basically, the user interface will provide users with information that is incorrect and misleading.

I'd think that, like other cases where WordPress functionalities depend on files stored on the filesystem that aren't part of a default installation e.g. patterns or plugins, the functionality should check whether those files exist. Of course, I do realize checking if file exists in the filesystem comes with performance concerns but there should be some check in place.

Ideally, like for plugins, the font should be deactivated and unlisted. For example, when plugin files get deleted, the plugin gets deactivated and a notice appears to inform users:

The plugin {plugin name} has been deactivated due to an error: Plugin file does not exist.

Step-by-step reproduction instructions

• Go to Site editor > Styles > Typography > Manage fonts
• In the Fonts modal dialog, go to the Google fonts and install a font e.g. 'Abel'.
• Close the Fonts modal dialog.
• If you didn't install any new font previously, a new 'fonts' directory is created in wp-content/fonts/.
• Locate the fonts directory and delete any font files.
• Refresh the editor page.
• Open the Fonts modal dialog again.
• Observe the font 'Abel' is still listed in the fonts Library.
• Observe your browser console reports an error 404.
• In my testing, I also get a random Uncaught DOMExceptionerror apparently initiated by loadFontFaceInBrowser. Screenshot:

Screenshots, screen recording, code snippet

No response

Environment info

No response

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

[colorful-tones]

I feel like there is potential overlap with #58411. If a user is looking to delete a font amongst fonts and they all have random string names then they’ll likely end up deleting the wrong one.

[matiasbenedetto]

The Font Library doesn't appear to handle these cases and for example still lists fonts as 'installed' even though the font files doesn't exist any longer. Basically, the user interface will provide users with information that is incorrect and misleading.

The installation consists of 2 parts: writing the file assets and storing the font family definition in the database. If you remove the font assets manually, you will end up with database records pointing to files no longer available on the file system. I think this follows the media library pattern. For example, if you upload an image file using the media library and then remove the image files created on disk, you will end up with empty images pointing to no longer available assets. Do you think that the font library should behave differently that the media library on that aspect?

[colorful-tones]

Do you think that the font library should behave differently that the media library on that aspect?

I'm glad you provided additional context and clarification, @matiasbenedetto 👍 I forgot that the Media Library behaves like this. It is undoubtedly critical to compare and consider existing components for UI/UX and even implementation.

However, it would alleviate concern from everyday builders if they encountered such a scenario that there would be any indication that the font files are gone. They can no longer utilize the font in their theme. In my current testing of the Font Library - if I delete a font in wp-content/fonts and then visit the Font Library, there is no indication that anything changed. At least with media, you see an empty square (from the screenshot above). Could we consider some messaging and interface indications that the font linkage has been broken? That seems like an ideal usability enhancement. 🤔

[matiasbenedetto]

if I delete a font in wp-content/fonts and then visit the Font Library, there is no indication that anything changed. At least with media, you see an empty square (from the screenshot above). Could we consider some messaging and interface indications that the font linkage has been broken? That seems like an ideal usability enhancement.

It's a fair point to consider. I would like to get @jasmussen's input about the interface.

[jasmussen]

This issue is not unique to the font library, it's in fact identical to the media library. If you delete files off your server, it's hard for WordPress to be aware of what happens. Here's what happens when you do that to an image in your media library. First, you have this placeholder:

I then proceeded to delete "placeholder.png" from wp-content/uploads. That's the first image in the media library screenshots above, here's what happens:

So in the above two screenshots shown after clearing cache and reloading the media library, the database item still exists.

I'd agree it would be nice if, across the WordPress media library and font library, to show some sort of error message indicating the file has been deleted from the server. There are probably technical questions to handle, but given the verbosity and complexity of the steps involved in getting yourself into this state, and that this behavior has been present in WordPress for perhaps a decade, I'd file this in the Enhancement category, and welcome PRs!

[afercia]

Not sure comparing with the media library is a good argument, no one said the media library behavior is ideal 🙂

it would alleviate concern from everyday builders if they encountered such a scenario that there would be any indication that the font files are gone.

there is no indication that anything changed. At least with media, you see an empty square

This's a fair point.

For fonts, it would be hard to understand, for example if a rendered font actually uses the 'real' weight 700 or if the browser resorts to the closer font-weight or it uses its own 'bold'.

[github-actions]

Hi,
This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
Thanks for helping out.

[afercia]

Thank you github-actions bot, this issue can still be reproduced following the steps in the description.

[peterwilsoncc]

I don't think there is anything WordPress can do about this.

As mentioned above, it's no different to the media library. For files with an associated post object in the database then the post object should be deleted in order to delete the files.

It's similar to deleting assets from a theme without modifying the references in the other files. It's going to cause problems.

I think this can be closed as unplanned.

[afercia]

I don't think there is anything WordPress can do about this.

Not my specific area of expertise but to my understanding there are ways to prevent this issue. WordPress already checks files on the filesystem, for example it does that for the theme files (even though for different purposes). It also checks missing plugin files, deactivates the plugin and prints out a notice 'The plugin {plugin name} has been deactivated due to an error: Plugin file does not exist' when plugin files are missing. WordPress also reads the plugins headers and does many other things to read files on the filesystem. Of course these checks have a cost in terms of performance but they can be mitigated.

it's no different to the media library

There are differences, for example:

• A missing media file e.g. an image will be immediately noticed by users because the browsers clearly shows the image is missing.
• A missing font file may not be noticed at all. For example if a 'bold' variant of a font is missing, the browser will fallback to the normal weight variant and it will apply its own 'bold' rendering. The visual difference may be barely noticeable.

[peterwilsoncc]

A missing font file may not be noticed at all. For example if a 'bold' variant of a font is missing, the browser will fallback to the normal weight variant and it will apply its own 'bold' rendering. The visual difference may be barely noticeable.

I think this is another reason to close the ticket as unplanned.

As the browser gracefully handles missing variants (some cases better than others) then removing a defined font variation because a file is missing creates more of a problem than it solves.

Deleting files from the uploads folder without deleting the associated post object is out of warranty behavior. The post objects are intended to be deleted via WordPress (be that the UI, WP-CLI, or an API request).

[afercia]

Deleting files from the uploads folder without deleting the associated post object is out of warranty behavior.

I'd argue that would appply to theme files as well, however we do safeguard against missing theme files.

[peterwilsoncc]

I'm not seeing safeguards for asset files, are you able to link to an example?

I know locate_template() and similar do file_exists() checks but that's more to do with supporting child themes and the template hierarchy than accounting for the deletion of assets.

Deleting fonts, images and stylesheets from various themes results in 404 errors in my testing.

[afercia]

Tnanks for pointing out the 404 issue. I think it's important to prevent those potential 404 when a font file is missing. Potentially, users may not ever notice a font file is missing and never notice the related 404s. I think WordPress should prevent them.