[wp-trac] [WordPress Trac] #40439: Save progress of intermediate image creation after upload

[WordPress Trac]

#40439: Save progress of intermediate image creation after upload
-------------------------------------------------+-------------------------
 Reporter:  mikeschroder                         |       Owner:
                                                 |  mikeschroder
     Type:  enhancement                          |      Status:  assigned
 Priority:  high                                 |   Milestone:  5.3
Component:  Media                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:  ui
  tests early                                    |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:31 mikeschroder]:
 > ...in this pass, I switched to using `_wp_create_image_subsizes` rather
 than have `multi_resize` update meta because the `WP_Image_Editor`
 abstraction is based around modification of a single image file rather
 than a WordPress attachment.

 Yes, that works better, thanks @mikeschroder.

 Was also thinking we should probably move these functions to a
 `WP_Image_Resize` or perhaps `WP_Image_Create_Subsizes` class? Can
 probably be just static. Then we can bring over other/existing functions
 that deal with resizing and generating the image meta, and just leave
 stubs outside the class. That would let us organize and name the new
 additions better, have some private vars and methods, etc.

 I'm almost done reviewing the patch. The last remaining thing to "grok" is
 how to handle (in a compatible way) the fact that
 `wp_generate_attachment_metadata()` actually creates the image sub-sizes
 rather than (only) generating the meta data :)

 Then we'll add the "multi-request" resizing to the same class. There we
 can look into the elapsed time since the current run started, similarly to
 how Site Health calculates file sizes, and trigger the next request when
 it is (perhaps) over 20 seconds? Would be a nice optimization.

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