Skip to content
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: Support alternate paths for fonts (WP_FONTS_DIR) #55063

Closed
jazzsequence opened this issue Oct 4, 2023 · 1 comment · Fixed by #57697
Closed

Font Library: Support alternate paths for fonts (WP_FONTS_DIR) #55063

jazzsequence opened this issue Oct 4, 2023 · 1 comment · Fixed by #57697
Assignees
Labels
[Feature] Typography Font and typography-related issues and PRs [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@jazzsequence
Copy link

What problem does this address?

For sites hosted on webhosts with immutable filesystems, installing fonts into wp-content is not a straightforward process unless those files are committed to an environment without those file write restrictions and deployed upstream. Providing a constant (or a filter) where a safe path can be defined allows users (or hosts) to be able to install fonts natively as intended without running into filesystem permission issues.

What is your proposed solution?

Introducing a constant, e.g. WP_FONTS_DIR which, like WP_CONTENT_DIR or WP_UPLOADS_DIR, allows a user to explicitly define an alternate path to installed fonts which is used instead of the default path (wp-content/fonts).

@ironprogrammer ironprogrammer added the [Feature] Typography Font and typography-related issues and PRs label Oct 4, 2023
@hellofromtonya hellofromtonya added the [Type] Bug An existing feature does not function as intended label Oct 5, 2023
@hellofromtonya
Copy link
Contributor

For context, the hosting discussion that led to this ticket being opened) happened in Make/Core slack in the #hosting channel https://wordpress.slack.com/archives/C3D6T7F8Q/p1696442869827259.

Providing the constant suggested in this ticket makes sense, to unblock web hosts supporting it.

As @jazzsequence noted in the slack thread:

I'm not picky about implementation, whether it's a constant or a filter, either would be equally easy to modify. But it would be considerably more infrastructure work (for us, and anyone else in a similar environment) to have to add a new symlink to support a hard-coded wp-content/fonts so a user could install fonts from a theme (or a plugin or wherever) without running into permissions errors across our entire fleet of WordPress sites.

IMO this needs to be done as part of the introduction of the Font Library into Core. cc @matiasbenedetto @azaozz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Typography Font and typography-related issues and PRs [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
No open projects
Status: Done
Status: Done
5 participants