[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 peterwilsoncc):

 My comment about preventing the removal of the font_dir filter was with
 regard to having done so during the introduction of the feature. That is,
 to have opened an enhancement at the time you approved the original PR
 adding a filter.

 >As I explained earlier this patch does not introduce a way for plugins to
 bypass the uploads_dir filter as used in core. Please have a look at the
 code again.

 I am not concerned about bypassing the uploads_dir filter in Core. I am
 concerned about introducing an entirely knew API to allow themes and
 plugins to do so. Secondly, I am concerned about the introduction of such
 an API being a maintenance burden for contributors.

 > Yea, I agree a lambda callback to a filter is somewhat unusual in core.
 It is quite common in plugins. However I don't see how that is a
 "maintenance burden" especially after the decision to revisit this code
 early in WP 6.6. I also don't see how using a lambda function is "against
 the coding standards". It is undesirable as those filter callbacks cannot
 be removed (easily). However in this particular case the fact that this is
 non-removable prevents plugins from mangling the Uploads API.

 > Yea, I agree a lambda callback to a filter is somewhat unusual in core.
 It is quite common in plugins. However I don't see how that is a
 "maintenance burden" especially after the decision to revisit this code
 early in WP 6.6. I also don't see how using a lambda function is "against
 the coding standards".

 Please refer to the coding standards on [https://developer.wordpress.org
 /coding-standards/wordpress-coding-standards/php/#closures-anonymous-
 functions closures]: "Closures should not be passed as filter or action
 callbacks, as removing these via remove_action() / remove_filter() is
 complex"

 This is why it becomes a maintenance burden. Core contributors unaware
 that the decision to go against the coding standards was intentional in an
 attempt to avoid an infinite loop when ''using the filter as documented''
 may reintroduce the bug.

 ----

 I don't think that [attachment:"60835.diff"] is appropriate code to
 introduce during the release candidate phase.

 This ticket has had multiple committers say the proposed API is a problem,
 multiple contributors have moved it off the milestone and the release is
 now in a phase [https://make.wordpress.org/core/2024/06/26/wordpress-6-6
 -release-candidate-phase/in which neither enhancements or existing
 regressions from previous versions of WordPress] can be committed.

 I think the best thing you could do for now is move this ticket off the
 6.6 milestone and spend some time reviewing feedback and reconsidering the
 approach. I've agreed to be co-tech lead on 6.7 and am willing to continue
 working towards a solution that doesn't introduce such a big change to the
 upload APIs.

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