[wp-trac] [WordPress Trac] #59040: Usage of new filter `image_edit_thumbnails_separately` in image editing logic breaks backward compatibility

WordPress Trac noreply at wordpress.org
Wed Aug 9 21:39:47 UTC 2023


#59040: Usage of new filter `image_edit_thumbnails_separately` in image editing
logic breaks backward compatibility
--------------------------+-----------------------------
 Reporter:  flixos90      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Media         |    Version:  6.3
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Follow-up to #57685 / [55935]: Unfortunately, [55935] is technically a
 breaking change that for example broke the image editing support of the
 WebP module in Performance Lab
 (https://github.com/WordPress/performance/pull/796).

 Maybe that's intended since intentionally the UI was disabled, but I
 personally find it an odd choice to "hide" even the underlying logic
 behind the new filter, which effectively disables logic that previously
 would have worked: Passing `thumbnail` or `nothumb` as image editing
 "target" is now pointless, while it would have worked before.

 Wouldn't it have been safer to simply hide the UI for this via filter (so
 that via WordPress UI you wouldn't be able to specify values other than
 `all`, but leave the underlying logic untouched?

 Since this is a very low-level function, I'm not sure it's worth a fix,
 but I wanted to flag it in any case. Noting though that the original
 ticket also has a `needs-dev-note` keyword, but it seems that a dev note
 was never published? For this kind of change, I think we should have one
 due to the above implications.

 cc @azaozz @peterwilsoncc @costdev

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59040>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list