[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