Make WordPress Core

Opened 5 weeks ago

Closed 3 weeks ago

#60751 closed task (blessed) (maybelater)

Add fallback for the default font folder path

Reported by: mmaattiiaass's profile mmaattiiaass Owned by:
Milestone: Priority: high
Severity: normal Version: 6.5
Component: Editor Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

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/

Change History (21)

This ticket was mentioned in PR #6252 on WordPress/wordpress-develop by @mmaattiiaass.


5 weeks ago
#1

  • Keywords has-patch has-unit-tests added

## 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

#2 @swissspidy
5 weeks ago

  • Component changed from General to Editor
  • Milestone changed from Awaiting Review to 6.5
  • Priority changed from normal to high

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

This ticket was mentioned in PR #6259 on WordPress/wordpress-develop by @mmaattiiaass.


5 weeks ago
#3

## 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

@mmaattiiaass commented on PR #6259:


5 weeks ago
#4

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

@mmaattiiaass commented on PR #6259:


5 weeks ago
#5

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

@swissspidy commented on PR #6259:


5 weeks ago
#6

@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.

@mmaattiiaass commented on PR #6259:


5 weeks ago
#7

@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

https://github.com/WordPress/wordpress-develop/assets/1310626/c95ead26-44de-4a3b-8ec0-4f95f13787b7

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

@swissspidy commented on PR #6259:


5 weeks ago
#8

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

@hellofromTonya commented on PR #6259:


5 weeks ago
#9

Whomever commits this, please also prop @costdev.

#10 @swissspidy
5 weeks ago

  • Type changed from enhancement to task (blessed)

@mmaattiiaass commented on PR #6259:


5 weeks ago
#11

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

@mmaattiiaass commented on PR #6259:


5 weeks ago
#12

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.

@azaozz commented on PR #6259:


4 weeks ago
#13

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).

@peterwilsoncc commented on PR #6259:


4 weeks ago
#14

@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)

https://github.com/WordPress/wordpress-develop/assets/519727/cfa6cdaf-26c0-40e5-910d-9e6529e34501

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

@azaozz commented on PR #6259:


4 weeks ago
#15

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.

This ticket was mentioned in PR #6292 on WordPress/wordpress-develop by @azaozz.


4 weeks ago
#16

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

@azaozz commented on PR #6259:


4 weeks ago
#17

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

@peterwilsoncc commented on PR #6259:


4 weeks ago
#18

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 commented on PR #6252:


4 weeks ago
#19

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 commented on PR #6292:


4 weeks ago
#20

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.

#21 @peterwilsoncc
3 weeks ago

  • Milestone 6.5 deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.