[wp-trac] [WordPress Trac] #55443: Create WebP sub-sizes and use for output

WordPress Trac noreply at wordpress.org
Thu Aug 18 20:06:30 UTC 2022


#55443: Create WebP sub-sizes and use for output
-------------------------------------------------+-------------------------
 Reporter:  adamsilverstein                      |       Owner:
                                                 |  adamsilverstein
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.1
Component:  Media                                |     Version:  6.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-unit-tests needs-dev-note        |     Focuses:
  needs-docs needs-user-docs needs-patch 2nd-    |  performance
  opinion needs-testing                          |
-------------------------------------------------+-------------------------

Comment (by jb510):

 Replying to [comment:118 adamsilverstein]:
 > Is it really a mess for the user though? I can see with your media
 developer hat it is a bit messy, but for end users nothing actually
 changes in the UI or when using images. The meta data accurately reflects
 the available images, and deleting the image correctly deletes all the sub
 sizes. Naming conflicts have also been carefully addressed. Even
 currently: if you edit an image in media, the filenames all have a hash
 appended and after multiple edits you end up with many hashed files making
 a "mess".

 I'm going to disagree and say this is messy for both developers and users.
 Years ago we taught users that they could truncate the webp extension to
 get the jpg if they needed a jpeg link  Don't get me wrong, we tell people
 all the time they shouldn't be right-click downloading images from the
 web, especially when they're usually the person that uploaded the original
 in the first place, yet we have a lot of authors that regularly do just
 that to reuse the images associated with their article when they re-post
 to social.

 ie.
 /wp-content/uploads/2022/08/0_AbbrLEQpkYjNgWkr.jpg.webp
 /wp-content/uploads/2022/08/0_AbbrLEQpkYjNgWkr.jpg

 It's just human nature to assume things like that will "just work".  Hence
 my comment 75 above.
 https://core.trac.wordpress.org/ticket/55443#comment:75

 Finally, a user story about this:

 As a user/blogger of WordPress, I want to run head first into WebP (and
 hopefully soon AVIF). While I appreciate the use cases that still require
 JPEG, I don't really care about them or the breakage (OG tags, feed,
 newsletters). I'm totally willing to accept those breakage edge cases
 given the choice. I'd much rather have the original + 100% WebP thumbnails
 stored. Then I'd delete 100% of Jpeg thumbnail images (not the original).
 I could also see OG and others eventually supporting webp, at which point
 how do we tidy up our already bloated media libraries at that point?

 However, this is a very different story as a developer working on very
 large publisher sites. There, I definitely need BOTH image types "forever"
 because there are millions of inbound links (hotlinking) to those images.
 Legacy 3rd party integrations from 15 years ago are critically important
 that they keep working.

 All this is why a simple media settings option is needed to enable this on
 demand for old sites instead of by default.  It's a single checkbox that
 gives site owners needed controls.  "Decisions not options" is about
 avoiding complexity, it's not about having zero options at all.

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


More information about the wp-trac mailing list