WordPress.org

Make WordPress Core

Opened 14 months ago

Last modified 2 months ago

#40439 new enhancement

Save progress of intermediate image creation after upload

Reported by: mikeschroder Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords: needs-patch
Focuses: Cc:

Description

When uploads fail with an HTTP Error, a user currently has no recourse other than to re-upload media and hope that it makes it the next time.

Currently, WordPress only saves data about intermediate sizes in meta after all of the sizes have been completed on upload. This means that every time a user attempts to re-upload, WordPress is required to resize *every* intermediate size necessary over again during this retry.

WordPress should save the progress of each successful image resize/intermediate so that it can be resumed on retry.

See #39647 for the global ticket on solving HTTP Error issues on upload.

Change History (8)

This ticket was mentioned in Slack in #core-media by mike. View the logs.


13 months ago

#2 @enshrined
13 months ago

If it's of any interest I had a play with this issue as a plugin here https://github.com/darylldoyle/WP-Background-Image-Processing.

It stops creating image sizes on upload and then uses the background processing library by deliciousbrains to create intermediate sizes in the background.

#3 @nosilver4u
13 months ago

Be careful with WPBIP if you have any batch image import processes on your site. I use the background lib from delicious brains in EWWW Image Optimizer, and it has a rather large issue with dispatching the queue. It doesn't reset the $data variable after saving it to the db, so you can end up with something like this: queue 1: 1 queue 2: 1,2 queue 3: 1,2,3 queue 4: 1,2,3,4 queue 5: 1,2,3,4,5 ... queue 10: 1,2,3,4,5,6,7,8,9,10 and so on. Import a couple hundred images, and you'll have a couple hundred queues with 1-200 items in them. There were some other issues with batch imports that I had to fix as well. You might be able to drop-in the background processing libs with the ones from EWWW IO: https://github.com/nosilver4u/ewww-image-optimizer/tree/master/vendor

This ticket was mentioned in Slack in #core-media by mike. View the logs.


11 months ago

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


10 months ago

This ticket was mentioned in Slack in #core-media by joemcgill. View the logs.


4 months ago

#7 @blobfolio
4 months ago

An alternative to a queue- or batch-type approach would be to alter image_get_intermediate_size() (and probably a few related functions) so that it consults the global $_wp_additional_image_sizes to see if a size exists (independently of the stored image meta), and run a basic file_exists()-type check to see if the file does indeed exist on the system, and if not, build it then and there.

The above would help WP recover from upload timeouts, and as an added bonus, help old media transition to new themes.

The main downside is that file_exists() lookup times can add up, particularly on Windows hosts. Another factor to consider is that this would potentially push thumbnail generation overhead to the frontend, which could lead to slow first loads (if i.e. a lot of thumbnails were missing).

To clarify, the Core wouldn't really be changing its default upload behaviors with the above approach. These changes would serve as more of a failsafe, catching and creating images that should exist but don't for whatever reason. :)

Last edited 4 months ago by blobfolio (previous) (diff)

This ticket was mentioned in Slack in #core-media by mike. View the logs.


2 months ago

Note: See TracTickets for help on using tickets.