[wp-trac] [WordPress Trac] #48522: Attachment size not generated when large images uploaded

[WordPress Trac]

#48522: Attachment size not generated when large images uploaded
-------------------------------------------------+-------------------------
 Reporter:  vanyukov                             |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  5.3.1
Component:  Media                                |     Version:  5.3
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion has-patch needs-testing  |     Focuses:
  needs-unit-tests                               |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:22 vanyukov]:
 > ...uploading a large image is not that uncommon. Future-proofing for the
 next 2-3 years is a great idea, in my opinion.

 Exactly! This is the reason two new larger image sub-sizes were added in
 5.3, to better handle larger and high-density displays. This is also the
 reason to make another sub-size and set it as "max size for web use".
 Typically many users upload unedited photos. These images are anywhere
 from about 3MB to 10MB in size. Serving these images for large screen
 devices is impractical,  hence the 2560px "full" size is made and is about
 700KB to 900KB.

 > Having a market share of 1/3 of the web, my opinion, WordPress should be
 a universal platform. All the use case scenarios should be supported "out
 of the box", without plugins and modifications. If it was my decision, I
 would prioritize for the future, not for the past. But it's easier to say
 than do, I understand that :-)

 Haha, I wish it was possible to "support all use case scenarios out of the
 box". However often one "edge case" is the exact opposite of another.
 Supporting one will make WP hard to use or incompatible with the other...
 This is one of the reasons why so many plugins exist, they add support for
 literally all possible use cases :)

 > But for the time being, I guess, this will have to do:
 > > Fail the upload and ask the user to upload a smaller image that is
 more suitable for web use.

 Yeah, this is a hard decision, but for now I think it is the proper one.
 Perhaps we can try to enhance this a bit by looking at the image file size
 before upload and warn the user when it is too large? That may make the
 user experience a little better (save some time) but still doesn't solve
 the underlying problem.

 Another possible solution would be to "tell" the user the image is too
 large and the server cannot post-process it. Then have the ability for the
 user to create the sub-sizes "by hand" and upload them separately. However
 that's going to be... a pretty complex task for many users:
 resizing/scaling the original image, saving each scaled image with
 different file name, cropping some of the scaled images... Still sounds
 like an "advanced" plugin.

 In these terms, what is the best solution to this ticket? Perhaps
 "surfacing" ImageMagick errors by adding `trigger_error();` in
 `wp_create_image_subsizes()` may be good. This functions is intended to
 initially create the sub-sizes after upload. But it should not be in
 `_wp_make_subsizes()` which is for more general use.

 Also, should it do `trigger_error();` on all internal/silent GD and
 ImageMagick errors or just on some?

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