Add fallback for the default font folder path

[mmaattiiaass]

Implement this design decision:

For installations that don’t support modification of the wp-content directory, the Font Library will use wp-content/uploads/fonts as a fallback location, ensuring 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.

Reference: ​https://make.wordpress.org/core/2024/03/07/unblocking-wp6-5-font-library-and-synced-pattern-overrides/

## What?

Add a fallback for the default font directory.

## Why?

For installations that don’t support modification of the wp-content directory, the Font Library will use wp-content/uploads/fonts as a fallback location, ensuring 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.

Decision from ​https://make.wordpress.org/core/2024/03/07/unblocking-wp6-5-font-library-and-synced-pattern-overrides/

## How?
Add the wp_default_font_dir function.
If /wp-content/fonts is writable this function should return:

array(
    'path' => '/var/www/src/wp-content/fonts',
    'url' => 'http://localhost:8889/wp-content/fonts',
    'subdir' => ''
    'basedir' => '/var/www/src/wp-content/fonts',
    'baseurl' => 'http://localhost:8889/wp-content/fonts'
    'error' => false
)

If /wp-content/fonts is not writable this function should return:
{{{php
array(

'path' => '/var/www/src/wp-content/uploads/fonts',
'url' => '​http://localhost:8889/wp-content/uploads/fonts',
'subdir' => '/fonts'
'basedir' => '/var/www/src/wp-content/uploads',
'baseurl' => '​http://localhost:8889/wp-content/uploads'
'error' => false

)
}}}
The output of this function is persisted in the database as a site_option. To refresh the value persisted the wp_default_font_dir function should be called like this wp_default_font_dir( true ).

---

Trac ticket: https://core.trac.wordpress.org/ticket/60751#ticket

[swissspidy]

Current discussion is happening at ​https://github.com/WordPress/gutenberg/issues/59699

## What?

Add a fallback for the default font directory.
Non persisted alternative of: ​https://github.com/WordPress/wordpress-develop/pull/6252

## Why?

For installations that don’t support modification of the wp-content directory, the Font Library will use wp-content/uploads/fonts as a fallback location, ensuring 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.

Decision from ​https://make.wordpress.org/core/2024/03/07/unblocking-wp6-5-font-library-and-synced-pattern-overrides/
Discussion: ​https://github.com/WordPress/gutenberg/issues/59699

## How?
Add the wp_default_font_dir function.
If /wp-content/fonts is writable this function should return:

array(
    'path' => '/var/www/src/wp-content/fonts',
    'url' => 'http://localhost:8889/wp-content/fonts',
    'subdir' => ''
    'basedir' => '/var/www/src/wp-content/fonts',
    'baseurl' => 'http://localhost:8889/wp-content/fonts'
    'error' => false
)

If /wp-content/fonts is not writable this function should return:
{{{php
array(

'path' => '/var/www/src/wp-content/uploads/fonts',
'url' => '​http://localhost:8889/wp-content/uploads/fonts',
'subdir' => '/fonts'
'basedir' => '/var/www/src/wp-content/uploads',
'baseurl' => '​http://localhost:8889/wp-content/uploads'
'error' => false

)
}}}
The output of this function is persisted in the database as a site_option. To refresh the value persisted the wp_default_font_dir function should be called like this wp_default_font_dir( true ).

---

Trac ticket: https://core.trac.wordpress.org/ticket/60751#ticket

There will need to be some tests to ensure against:

• infinite loops (as noted)
• fallback applies when expected
• fallback does not apply when it isn't expected

If neither directory can be created then error should be defined and return a similar result to wp_upload_dir().

I thought about these 2 alternatives for testing this functionality but they didn't work on my end:

1. use chmod() in the test body to change the permissions of the path (it seems to be ignored, and wp_is_writable always returns true in the unit test env).
2. try to mock the wp_is_writable( $path ) function in the context of the unit test. (I couldn't mock this global function. I found examples in the core's codebase about mocking class methods but not functions in the global scope).

Any help bout how to test this functionality is welcome.
cc. @peterwilsoncc @swissspidy @youknowriad

If neither directory can be created then error should be defined and return a similar result to wp_upload_dir().

Added here: ​https://github.com/WordPress/wordpress-develop/pull/6259/commits/d2f6e5c03ef6ed041a7dfb6f71ecfda4dce3504b

@matiasbenedetto Which test is this in context of? This PR does not have any tests, but I do see tests at #6252. The chmod() there actually works just fine for me.

Some of my recent l10n tests also use chmod without issues, so I don't see why that would be an issue here.

If you can point me at the code this is in reference to, I am happy to take a look.

@matiasbenedetto Which test is this in context of? This PR does not have any tests, but I do see tests at #6252. The chmod() there actually works just fine for me.

The test using chmod is failing in #6252 CI: ​https://github.com/WordPress/wordpress-develop/actions/runs/8251059911/job/22567291729?pr=6252

Some of my recent l10n tests also use chmod without issues, so I don't see why that would be an issue here.

If you can point me at the code this is in reference to, I am happy to take a look.

I added the same kind of test using chmod in this PR to test here too but is failing on my local env and in the CI: ​https://github.com/WordPress/wordpress-develop/pull/6259/commits/9c51258044730882a6e1e50e747882a16869f02e

@matiasbenedetto The test needs to be more robust and properly cleanup during teardown. Just pushed a first step towards this.

Whomever commits this, please also prop @costdev.

the function test_fonts_dir_with_filter() might be better named test_font_dir_filter(), as the filter name is font_dir.

Done here: ​https://github.com/WordPress/wordpress-develop/pull/6259/commits/f0c3f3dfb3bfe0aa02352e55932c754458130ca7

Thanks everyone for the contributions.

In the last commits, I tried to implement the remaining feedback.
I updated the PR description with all the cases being tested and their expected returned values.
I think it is ready for another review.

Trying an alt solution in ​https://github.com/matiasbenedetto/wordpress-develop/pull/1. It simplifies the code a bit and only depends on wp_is_writable( WP_CONTENT_DIR ) to determine whether to move the /fonts dir or not.

Also has an optional param tell wp_get_font_dir() whether to actually make the directory or just get the path/data for it (works similarly to wp_upload_dir() $create_dir param).

@azaozz The alternative PR in to this branch doesn't work as it can place font files in uploads/fonts on the first install and wp-content/fonts on the second install. If the content directory doesn't exist initially for an upload it's created.

See the gif attached (in my local setup wp-content is simply content)

It also causes further lock in to having to work around the infinite loop bug rather than fix it.

it can place font files in uploads/fonts on the first install and wp-content/fonts on the second install

You mean WP_CONTENT_DIR is non-writable on the first try to install a font and suddenly becomes writable when trying to install fonts for the second time? Otherwise how can WP ever place files in a non-writable directory?

It also causes further lock in to having to work around the infinite loop bug rather than fix it.

But the fix for that infinite loop is to not use a filter there at all, just do a simple "override" like the rest of _wp_upload_dir(). Imho there is no good reason for that lambda filter anyway. Discussion: ​https://github.com/WordPress/wordpress-develop/pull/6211#issuecomment-2005459537.

An alternative to ​https://github.com/WordPress/wordpress-develop/pull/6259. Reuses some of the code from there.

Trac ticket: https://core.trac.wordpress.org/ticket/60751

Made the alt patch into a stand-alone PR (as requested): ​https://github.com/WordPress/wordpress-develop/pull/6292

Closing this PR off per ​https://make.wordpress.org/core/2024/03/21/font-library-update-storage-of-font-files/. Thanks everyone for your work on this, I appreciate it.

Closing this PR off per ​https://make.wordpress.org/core/2024/03/21/font-library-update-storage-of-font-files/. Thanks everyone for your work on this, I appreciate it.

Closing this PR off per ​https://make.wordpress.org/core/2024/03/21/font-library-update-storage-of-font-files/. Thanks everyone for your work on this, I appreciate it.

[peterwilsoncc]

Closing this off as maybelater per ​https://make.wordpress.org/core/2024/03/25/wordpress-6-5-release-delayed-1-week/