[wp-trac] [WordPress Trac] #64411: Media Library - Large Image Size Uploads

[WordPress Trac]

#64411: Media Library - Large Image Size Uploads
-------------------------------------------------+-------------------------
 Reporter:  irgordon                             |      Owner:  (none)
     Type:  enhancement                          |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  General                              |    Version:  6.9
 Severity:  normal                               |   Keywords:  needs-
  Focuses:  javascript, performance, php-        |  testing
  compatibility                                  |
-------------------------------------------------+-------------------------
 Needs to handle large image uploads better for various server
 configurations natively.

 To improve the Media Library's stability with 10MB+ assets, we need to
 revisit the default plupload_init configuration. Currently, the uploader
 often defaults to a monolithic POST request, which subjects large binaries
 to strict upload_max_filesize and max_execution_time limits. By enforcing
 a chunk_size (e.g., 1024KB) within the plupload parameters filter, we can
 segment the upload into smaller HTTP requests. This approach isolates
 failures to individual chunks rather than the entire file and effectively
 bypasses per-request size limits, significantly reducing failure rates on
 unstable client connections.

 Regarding post-processing, the big_image_size_threshold introduced in 5.3
 creates a bottleneck for high-resolution uploads. When the core attempts
 to immediately uncompress and scale a 10MB+ image (often exceeding the
 2560px threshold), the memory footprint for the GD resource can spike
 instantly, leading to OOM (Out of Memory) fatal errors before the
 attachment metadata is even generated. We should consider handling these
 exceptions more gracefully or allowing the threshold to be bypassed
 programmatically via big_image_size_threshold when memory is detected to
 be insufficient, preventing the "hanging" upload experience.

 Finally, we should look at the prioritization of WP_Image_Editor
 implementations. GD struggles with large pixel buffers compared to
 ImageMagick; preferring Imagick where available would mitigate memory
 exhaustion during resizing operations. Additionally, for the chunk
 reassembly phase, we need to ensure the environment's max_execution_time
 is sufficient (ideally 300s+) to handle the I/O overhead of stitching the
 file parts back together on the server side.

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