[wp-trac] [WordPress Trac] #60652: font_dir filter enters an infinite loop if wp_get_upload_dir() is used in the filter callback

[WordPress Trac]

#60652: font_dir filter enters an infinite loop if wp_get_upload_dir() is used in
the filter callback
-------------------------------------------------+-------------------------
 Reporter:  mmaattiiaass                         |       Owner:
                                                 |  peterwilsoncc
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  6.5.1
Component:  General                              |     Version:  6.5
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-unit-tests has-patch fixed-      |     Focuses:
  major dev-reviewed                             |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:55 peterwilsoncc]:

 > I'm surprised I need to but I will explain how the Fonts PHP API works:

 Thanks for the explanation.

 > In order to upload or sideload files, it's required to add a filter to
 the `upload_dir` filter. Without applying the filter files will upload to
 the default `uploads/yyyy/mm` directory.

 Think I see where the misunderstanding comes from. It is **not required**
 to use the `upload_dir` filter in order to upload a font. It is only
 required to pass the correct information/context about where the /fonts
 directory is located, as stated below.

 > I agree that it would probably be better if an upload context was added
 to the upload handlers and related functions but a ticket for the
 enhancement was not opened during the development of the Fonts API so by
 the time it was committed to beta 1 it was too late to do so.

 Yes, this seems to be the other part of the misunderstanding. Imho not
 using a filter when one is not needed (and causes infinite loops) is an
 essential part of this code, not an enhancement. Fixing the infinite loop
 possibility by removing the filter is the correct patch here, regardless
 of beta or RC.

 Anyway, planning to fix that in #60835 and commit early to 6.6.

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