[wp-trac] [WordPress Trac] #60835: Fix and improve handling of uploading of font files

[WordPress Trac]

#60835: Fix and improve handling of uploading of font files
----------------------------------------------------+---------------------
 Reporter:  azaozz                                  |       Owner:  (none)
     Type:  defect (bug)                            |      Status:  new
 Priority:  high                                    |   Milestone:  6.6
Component:  Upload                                  |     Version:  6.5
 Severity:  normal                                  |  Resolution:
 Keywords:  needs-testing has-patch has-unit-tests  |     Focuses:
----------------------------------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:64 joemcgill]:
 > Have any issues been reported that show that removing the `font_dir`
 filter is causing critical bugs in production?

 I don't think so as there are no plugins that exhibit this "bad behavior"
 for now, as far as I see. However are you asking whether removing part of
 the Uploads API in WP should be considered a big?

 > Again, this seems like an enhancement (preventing removal of the /fonts
 directory) that is needed in order to support future functionality—not
 something required for 6.6, so it doesn't appear to be a blocking issue.

 Having a `/fonts` directory (whether it ids `wp-content/uploads/fonts` or
 any other place) is a base part of the WP Uploads API. Not having a
 `/fonts` directory is a major breakage of the design and of the intended
 behavior when storing fonts.

 Of course, plugins can choose to do that. Plugins can also choose to
 remove the `/themes` and/or `/plugins` directories and store themes and
 plugins in `/wp-content` instead. That doesn't make it good or acceptable,
 and imho such plugins should be marked as exhibiting bad behavior.

 > > Could you please specify what changes exactly?
 >
 > Sure! My understanding of the PR is that it modifies the uploads API by
 adding a new parameter to `wp_upload_bits()` so the directory where files
 will be uploaded is directly passed to the function rather than applied as
 a filter. This feels like a significant change to a low level (and
 foundational) API that should be made as part of an enhancement ticket,
 rather than as an implementation detail to a bug fix.

 What is the difference (mostly from plugins point of view) between passing
 these settings as a param to the `wp_upload_bits()` function vs. using the
 `upload_dir` filter to pass them? Short answer: there is no difference.

 Please note that plugins are able to use the new parameter on
 `wp_upload_bits()` and on `_wp_handle_upload()` only when using these
 functions directly. This is not possible when core is using these
 functions. In these cases there are no changes to the current behavior.

 > I think this would be better to go into trunk early so it has time to
 soak given additional changes...

 Don't think there are any significant architectural changes in this patch.
 The only change is that it prevents plugins from making the WP Uploads API
 inconsistent. Also, this was once punted from #60652 as being too close to
 the WP 6.5 release. Now, despite all the delays, it is not so close to the
 WP 6.6 release expected in about three weeks. Do you think three weeks is
 not enough time for this to be reviewed?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60835#comment:65>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform